Une approche de composition de services Web à l aide des Réseaux de Petri orientés objet

Transcription

1 RÉPUBLIQUE ALGÉRIENNE DÉMOCRATIQUE ET POPULAIRE MINISTÈRE DE L'ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE SCIENTIFIQUE UNIVERSITÉ ABDELHAMID MEHRI, CONSTANTINE 2 FACULTÉ DES SCIENCES DES NOUVELLES TECHNOLOGIES DE L INFORMATION ET DE LA COMMUNICATION DÉPARTEMENT D INFORMATIQUE FONDAMENTALE ET SES APPLICATIONS LABORATOIRE MISC Année : 2014 N d ordre : LMD/ NTIC/ 2014/ 004. Série : LMD/ NTIC/ 2014/ 004. Thèse de Doctorat en informatique Titre : Une approche de composition de services Web à l aide des Réseaux de Petri orientés objet Présentée par : Sofiane Chemaa. Date de soutenance: 07/12/2014. Composition du Jury Pr. Zizette Boufaida Université Constantine 2 Président Pr. Allaoua Chaoui Université Constantine 2 Rapporteur Pr. Djamel Meslati Université Badji Mokhtar-Annaba Examinateur Dr. Hammadi Bennoui Université Mohamed Khider- Biskra Examinateur Dr. Abdelhafid Zitouni Université Constantine 2 Examinateur

2 Tout d abord, je remercie Dieu le Tout Puissant de m avoir donné le courage et la force pour mener à bien ce travail. Je tiens avant tout à exprimer ma profonde gratitude à Monsieur Allaoua Chaoui, professeur à l université Constantine 2, qui m a fait l immense honneur d être mon promoteur, pour m avoir dirigé dans l élaboration de cette thèse. Son encadrement, ses critiques constructives, ses précieux conseils, ses relectures pointilleuses m ont été d une aide précieuse. Pour tout cela ainsi que pour sa confiance, ses encouragements ininterrompus, le climat agréable de travail, et sa disponibilité du début à la fin de l élaboration de cette thèse, je le remercie vivement et qu il trouve ici l expression de ma considération profonde. Je remercie Madame Zizette Boufaida, professeur à l université Constantine 2, d avoir accepté de présider le jury. Je remercie également l honorable jury composé de Messieurs : Pr. Djamel Meslati, Dr. Hammadi Bennoui et Dr. Abdelhafid Zitouni d avoir accepté d examiner ce travail. Je tiens à remercier aussi tous ceux qui m ont soutenu et qui ont contribué de près ou de loin à l élaboration de ce travail.

3 Je dédie ce modeste travail A Mes chers parents A Mes sœurs A Mon neveu Abderrahmane A Mes nièces Meriem et Alaâ A Toute ma famille A Tous mes amis

4 ملخص ف أ اي ا هز أصبسج خذياث انى ب كث شة االسخخذاو خصىصا ي لبم انششكاث و رنك ي اخم عشض أع انهى وب ا احهى عبش شبكت اال خش ج. حعخبش ع ه ت حشك ب خذياث انى ب ي اكثش ان ىاض ع انخ خهبج اهخ او انبازث ز ث ا ها ح ك ي يعاندت ان شاكم ان عمذة باالعخ اد عه خذياث و ب بس طت اخشي انع ه ت يعمذة خذا وحخطهب اسخع ال حم اث ي هد ت ي اخم ا داصها. ف اطاس هز االطشوزت مخشذ يماسبت يىخهت بىاسطت ان ارج ي اخم ورنك ي خالل انخعاو ف ا ب هى غ ش أ هز زخت حشك ب و فسص خذياث انى ب. ف هزا انس اق عانح يشكهت زخت وحشك ب خذياث انى ب باسخخذاو شكه ت يشحكضة عه شبكاث بخش حذع.«G-Net» بان ماس ت يع ان ماسباث األخشي هزا ان فهىو ىفش آن اث فعانت ولى ت حس ر ب زخت ان ظى ان عمذة. هز ا ن اث غ ش يعخ ذة زخ ي لبم شبكاث بخش عان ت ان سخىي. ف هزا انصذد مخشذ ا ضا ي يد ىعت انمىاعذ ان شحكضة ارج عه «G-Nets» وانخ حس ر بسم إشكان ت حشك ب خذياث انى ب. ف ا خص انفسص ان هد نع ه ت حشك ب خذياث انى ب: ف خطىة أون سخخذو حم ت حس ر بخسى م ارج «G-Nets» ان ارج يعادنت «PrT-Nets» و رنك ي أخم حطب ك حم اث انخسه م ان هد ان خازت ن ارج «PrT-Nets» عه يىاصفاث «G-Nets». ف خطىة ثا ت مخشذ طش مت بذ هت حس ر بخسى م ىرج Services» «G-Net ان يىاصفت يىافمت.«Maude» انهذف ي هزا انخسىل هى االسخفادة ي يخخهف أدواث ان ساكاة وانخسمك انخاصت بهغت انىصف و انبشيدت.«Maude» أخ شا مذو أداة «Java» حس ر بخشك ب خذياث انى ب ان ىصىفت باسخع ال ارج Services» «G-Net بطش مت آن ت كم هزا اعخ ادا عه ىرج فىل يعشف ي اخم هز ان ارج و عه يد ىعت لىاعذ انخشك ب ان عشفت ي هد ا. هز األداة حس ر ا ضا باالسخخشاج االن ن ىاصفاث.«G-Net Services» ا طاللا ي ارج «Maude» الكلمات المفتاحية: خذياث انى ب حشك ب خذياث انى ب انخسم ك ان هد شبكاث ب خش G-Net Service G-Net لىاعذ انخشك ب حسى م ان ارج ىرج فىل.Maude LTL Model Checker Maude

5 Résumé De nos jours, les services web sont devenus très utilisés notamment par les entreprises pour rendre accessible leurs métiers et leurs données via le Web. La composition des services web est un sujet qui suscite l intérêt des chercheurs, elle offre la possibilité de traitement de problèmes complexes même avec des services simples existants tout en coopérant entre eux. Toutefois, cette tâche reste très complexe et nécessite pour son accomplissement des techniques formelles. Dans ce travail, nous proposons une approche dirigée par les modèles pour la modélisation, la composition et la vérification formelle des services web. Dans cette optique, nous abordons le problème de la modélisation et de la composition des services web en utilisant un formalisme basé sur les réseaux de Petri, appelé G-Net. Par rapport aux autres approches, ce concept offre des mécanismes efficaces et puissants pour la modélisation des systèmes complexes qui ne sont pas supportés, même par les réseaux de Petri de haut niveau. Dans ce contexte, nous proposons une algèbre basée sur les G-Nets qui résout avec succès la composition complexe des services web. En plus d un formalisme permettant de décrire la structure et le comportement des services, l'approche proposée fournit un ensemble représentatif d opérateurs présentés par le biais de leur syntaxe et de leur sémantique. Concernant la vérification formelle de la composition des services web : dans un premier temps, nous utilisons une technique permettant de transformer les modèles G-Nets vers des modèles de réseaux de Petri Prédicats/Transitions (PrT-Nets) équivalents dans le but d appliquer les techniques d'analyse formelle des PrT-Nets sur les spécifications G-Nets. Dans un deuxième temps, nous proposons une autre approche qui permet de translater un modèle G-Net à une spécification Maude équivalente. L objectif de cette transformation est de bénéficier des différents outils de simulation et de vérification basés Maude (tel que, Maude LTL Model Checker). Enfin, nous présentons un outil java qui permet d automatiser cette approche en se basant sur l utilisation d un méta-modèle défini pour les G-Net services et sur l ensemble des opérateurs définis formellement. Cet outil permet également de générer des spécifications Maude à partir des modèles G-Net services. Mots clé : Services web, Composition des services web, Vérification formelle, Réseaux de Petri, G-Nets, G-Net services, Algèbre de composition, Transformation de modèles, Métamodèle, PrT-Nets, Logique de réécriture, Maude, Maude LTL Model Checker.

6 Abstract In our days, web services have become very used mainly by the companies to make available their business and data via the Web. The web services composition is a topic that attracts the interest of researchers. It offers complex problems process ability even with simple existing web services while cooperating with each other. However, this task remains highly complex and requires modeling tools and formal techniques for its completion. In this work, we propose a model-driven approach for the modeling, the composition and the formal verification of web services. In this respect, we address the web service composition problem using a Petri net based framework called G-Net. Unlike other approaches, this concept offers efficient and powerful mechanisms for complex systems modeling which are not supported even by high level Petri nets. In this context, we propose a G-Net based algebra for composing web services that successfully solves complex composition. The proposed approach provides not only a formalism to describe Web services structure and behavior but also a representative set of operators presented by means of syntax, semantics and the resulting composite service. Concerning the web services composition formal verification, at first, we use a technique that permits to transform the G-Net models into equivalents Predicate/Transition net models (PrT-Nets) in order to apply formal analysis techniques of PrT-Nets on G-net specifications. Subsequently, we propose an alternative approach that permits the translation of a G-net service model into an equivalent Maude specification. The aim of this transformation is to benefit from the various simulation and verification tools based Maude (such as: Maude LTL Model Checker). Finally, we present a Java tool that permits to automate this approach based on the use of a meta-model defined for G-Net services and on the composition rules set. This tool can also generate Maude specifications from G-Net service models. Keywords: Web services, Web services composition, Formal verification, Petri-Nets, G-Nets, G-Net services, Algebra, Model transformation, Meta-model, PrT-Nets, Rewriting logic, Maude, Maude LTL Model Checker.

7 «Table des Matières» «Introduction générale» 1. Introduction Problématique Contributions Organisation du document Vue globale Contenu des chapitres...5 Chapitre 1 : «Les services web» 1. Introduction Définition Architecture des services web Langages et protocoles utilisés par les services web Le langage XML (Extensible Markup Language) La couche de Transport La couche de Communication (SOAP) La couche de Description (WSDL) La couche de Découverte et de Publication (UDDI) Composition des Services Web Définition Cycle de vie d une composition de services Orchestration et Chorégraphie Les types de composition des services web Composition manuelle, semi-automatique et automatique Composition statique et composition dynamique Langages de composition de services web Le langage BPEL Approches de modélisation et de composition des services web Les automates Les diagrammes d activité UML Les algèbres de processus Les réseaux de Petri Conclusion...34 Chapitre 2 : «L ingénierie dirigée par les modèles» 1. Introduction Concepts fondamentaux de l ingénierie dirigée par les modèles Système Point de vue Architecture Modèle Application Plateforme Modèles et formalismes de modélisation...38 [I]

8 «Table des Matières» 4. Méta-modèles et méta-modélisation Transformation de modèles Types de transformations Classification des approches de transformation de modèles Transformation Modèle vers Modèle (M2M : Model-to-Model) Transformation Modèle vers Code (M2T : Model-to-Text) Manipulation des modèles L architecture dirigée par les modèles (ADM) Définition Typologie des modèles dans l ADM Cycle de développement de l approche ADM L architecture à quatre niveaux Transformation de graphes Notion de graphe Graphe non-orienté Digraphe Grammaire de graphe Règle de transformation Système de transformation de graphe Conclusion...55 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» 1. Introduction Les réseaux de Petri Définition informelle Définition formelle Fonctionnement d un réseau de Petri ordinaire Validation d une transition Franchissement d une transition Séquences de franchissement Graphe des marquages accessibles Modélisation des systèmes complexes en utilisant les réseaux de Petri Le parallélisme La synchronisation La synchronisation mutuelle La synchronisation par signal Le partage de ressources La mémorisation Extensions des réseaux de Petri Les G-Nets G-Nets et systèmes G-Net Structure des G-Nets...67 [II]

9 «Table des Matières» Structure de jetons Franchissement d une transition Invocation d un G-Net La logique de réécriture Théorie équationnelle Signature Algèbre Les terme équation Spécification algèbrique Théorie de réécriture Règles de déduction Modèle d une théorie de réécriture Le langage Maude Caractéristiques du langage Maude Syntaxe du langage Maude Les sortes Les sous sortes Les opérations La surcharge des opérateurs Les variables Les équations Les règles de réécriture Importation des modules Les modules Les modules fonctionnels Les modules systèmes Les modules orientés objet Les niveaux de programmation Maude Core Maude Full Maude Conclusion Chapitre 4 : «Une approche intégrée G-Nets/Maude pour la modélisation, la composition et la vérification des services web» 1. Introduction Les services web en tant que G-Net services Les G-Net Services Les services Web Composition des services web Les Constructeurs de composition Sémantique formelle Service vide...92 [III]

10 «Table des Matières» Séquence Alternatif Itération Séquence arbitraire Parallèle Discriminateur Sélection Raffinement Remplacement Vérification formelle des services web Une technique de vérification basée réseaux de Petri Prédicats/Transitions Une technique de vérification basée Maude Conclusion Chapitre 5 : «Implémentation et étude de cas» 1. Introduction Outils technologiques utilisés Langage de programmation Environnement de développement Affichage graphque Implémentation Etude de cas Modélisation Raffinement Vérification Technique basée PrT-Nets Génération du modèle PrT-Net équivalent Génération de la description PROD Technique basée Maude Génération de la spécification Maude équivalente Analyse formelle avec Maude LTL Model Checker Conclusion «Conclusion générale» 1. Bilan Phase théorique Phase technique Perspectives [IV]

11 «Table des Figures» Figure 1 : Exemple de planification d un voyage...3 Figure 1.1 : Architecture de base des services web...10 Figure 1.2 : La pile Protocolaire simplifiée des services web...11 Figure 1.3 : Schéma d un message SOAP...13 Figure 1.4 : Structure d une description WSDL Figure 1.5 : Exemple d un document WSDL...17 Figure 1.6 : Le contenu de l annuaire UDDI...18 Figure 1.7 : Les structures de données d UDDI...19 Figure 1.8 : Cycle de vie d une composition de services web...22 Figure 1.9 : Principe de l'orchestration des services Web...23 Figure 1.10 : Principe de la chorégraphie des services web...24 Figure 1.11 : Structure d un fichier BPEL...27 Figure 2.1 : Relation entre système, modèle et méta-modèle...39 Figure 2.2 : Concepts de base de la transformation de modèles...40 Figure 2.3 : Les approches de transformation de modèles...44 Figure 2.4 : Le cycle de développement en Y...48 Figure 2.5 : Architecture à quatre niveaux...49 Figure 2.6 : Graphe non-orienté (A)...51 Figure 2.7 : Graphe (A) et sous-graphe (B)...51 Figure 2.8 : Digraphe Figure 2.9 : Graphe orienté étiqueté...52 Figure 2.10 : Les étapes d application d une règle de transformation...54 Figure 2.11 : Système de réécriture de graphe...55 Figure 3.1 : Exemple d un réseau de Petri marqué...58 Figure 3.2 : Franchissement de transition...61 Figure 3.3 : Graphe de marquages...62 Figure 3.4 : Exemple de parallélisme...62 Figure 3.5 : Synchronisation mutuelle...63 Figure 3.6 : Synchronisation par signal...64 Figure 3.7 : Exemple d un partage de ressource...64 Figure 3.8 : Exemple de mémorisation...65 Figure 3.9 : Notations utilisées pour représenter un G-Net...67 Figure 4.1 : Schéma illustratif des différentes phases de notre approche...84 Figure 4.2 : Exemple de G-Net services [V]

12 «Table des Figures» Figure 4.3: Services S 1, S 2,, S n...91 Figure 4.4 : Service vide...92 Figure 4.5 : Service...93 Figure 4.6 : Service...94 Figure 4.7 : Service...95 Figure 4.8 : Service...96 Figure 4.9 : Service Figure 4.10 : Service Figure 4.11 : Service étendu Figure 4.12 : Service [ ] Figure 4.13 : Exemple de raffinement Figure 4.14 : Services et Figure 4.15 : Principes de transformation des G-Nets vers PrT-Nets Figure 5.1 : Méta-modèle des G-Net services Figure 5.2 : Scénario de la composition Figure 5.3 : Scénario de la génération des spécifications Maude Figure 5.4 : Fenêtre principale de l application Figure 5.5 : Service «Am-books» Figure 5.6 : Formulaire de spécification Figure 5.7: Fichier «Am-books.txt» Figure 5.8: Fichier «Am-books.dot» Figure 5.9: Liste d opérateurs de composition Figure 5.10: Le bloc bien formé «BL» Figure 5.11: Le G-Net service résultant «Amazon-Books» Figure 5.12 : Le G-Net service «Amazon-Books» sous AToM Figure 5.13: Le modèle PrT-Net équivalent au G-Net service «Amazon-Books» Figure 5.14: La description PROD générée Figure 5.15: La spécification Maude générée Figure 5.16: Résultats de la vérification [VI]

13 Introduction générale

14 «Introduction générale» 1. Contexte L internet a transformé le monde en un immense marché virtuel où le client potentiel peut commander et acheter des articles de son choix assis juste en face d un ordinateur. Cette technologie permet aux utilisateurs d'effectuer des transactions en ligne. L évolution d internet et l émergence de la technologie «e-business» ont influencé les stratégies des entreprises. Par conséquent, ces dernières doivent non seulement assurer l intégration et l interopérabilité de leurs applications au niveau interne mais aussi au niveau partenaire (B2B : Business To Business). Ces applications sont généralement appelées processus métiers. Pour gérer et automatiser le cycle de vie de ces processus, les entreprises adoptent l architecture orientée service (SOA). Selon le Gartner Group 1, plus de 75% des projets d entreprise reposeront sur l architecture orientée service. Cette dernière est née pour répondre aux inconvénients des technologies orientées composants. Son but est d offrir des solutions aux différents problèmes dont les intergiciels conventionnels comme CORBA (Common Object Request Broker Architecture) [1] et DCOM (Distributed Component Object Model) [2] ont été incapables de résoudre. Les intergiciels ont été développés à une époque où les systèmes distribués étaient limités à un réseau local ou privé d une entreprise. Ils ont pour objectif de partager et de réutiliser des codes existants, en faisant des appels de procédures distantes. Mais ces tentatives n ont pas pu passer à l échelle, et elles n étaient utilisées que localement à l intérieur des entreprises. Les principaux inconvénients des intergiciels [3] sont : Le couplage fort des composants. La complexité d utilisation et de mise en œuvre de ces intergiciels. Le non support de certains protocoles du web (HTTP, SMTP, etc.). La non standardisation (dans certains cas). Contrairement aux architectures orientées composants, l architecture orientée service est caractérisée par son couplage faible, son indépendance par rapport aux plateformes, et sa grande capacité d intégration et de réutilisation. 1 [1]

15 «Introduction générale» Dans la littérature, nous pouvons trouver plusieurs définitions relatives à l architecture orientée service. Selon Nicolai Josuttis, «L architecture orientée service est un paradigme permettant d organiser et d utiliser des savoir-faire distribués pouvant être de domaines variés. Cela fournit un moyen uniforme d offrir, de découvrir, d interagir et d utiliser des savoir-faire pour produire le résultat désiré avec des pré-conditions et des buts mesurables» [4]. Jennings et al. ont défini l architecture orientée service comme étant «une structure d intégration de processus métier qui supporte une infrastructure des technologies d information comme étant des composants et services sécurisés, standardisés et qui peuvent être combinés pour s adresser aux priorités de changements métiers» [5]. Les services web [6] constituent la technologie actuelle la mieux placée pour mettre en place l architecture orientée services. Le concept de service web fait référence essentiellement à une application mise à disposition sur Internet par un fournisseur de service et accessible par des clients à travers des protocoles Internet standards. Ces services se basent sur un ensemble de protocoles et de langages standards permettant de faciliter leur mise en œuvre. «WSDL» [7] est un langage reposant sur XML, il permet de décrire l interface du service web, son emplacement et la manière de l'invoquer. «SOAP» [8] est un protocole permettant de structurer les messages échangés entre les services. «UDDI» [6] est un service d'annuaire qui contient les publications des services web et permet à ses clients de les localiser et de découvrir leurs détails. La technologie des services web soulève des problèmes de recherche très intéressants parmi lesquels nous pouvons citer: la modélisation : comment spécifier la syntaxe et la sémantique d un service sans ambiguïté? la composition : comment assembler plusieurs services atomiques et composites pour un travail particulier? la vérification : comment valider la composition des services web? la découverte : comment trouver le meilleur service pour un travail particulier? la surveillance : comment surveiller l exécution d un service unitaire ou composite? le diagnostic : comment détecter et isoler les fautes au cours de l exécution d un service unitaire ou composite? [2]

16 «Introduction générale» la réparation : comment et quand faut-il réagir pour corriger une situation d erreur? l hétérogénéité : comment résoudre le problème de l hétérogénéité au niveau des données entre les services web? Dans ce travail nous nous intéressons aux trois premiers axes de recherche à savoir la modélisation, la composition et la vérification formelle des services web. 2. Problématique Les services web sont des composants conceptuellement limités à des fonctionnalités relativement simples qui sont modélisées par un ensemble d opérations. Généralement, un seul service ne peut répondre aux besoins des clients qui sont de plus en plus complexes. Prenons l exemple de la figure ci-dessous. Pour partir en vacance une personne doit trouver un service web pour chaque réservation qu elle désire effectuer (réservation de train, d avion, d hôtel, etc.). Pour résoudre ce problème, des services Web peuvent être regroupés et interconnectés pour former un seul service du point de vue utilisateur. C est ce qu on appelle la composition de services web. Cette dernière permet de créer un service composite offrant une nouvelle fonctionnalité à partir des services web existants plus simples. Réserver Train Réserver Train Réserver Avion Réserver Avion Louer Voiture Louer Voiture Réserver Hôtel Réserver Hôtel Figure 1 : Exemple de planification d un voyage [3]

17 «Introduction générale» Bien que la description WSDL est indispensable pour connaître les informations essentielles à l interaction entre les services, elle montre vite ses limites. En effet, elle représente une description de l interface d un service web, et modélise une interaction sans mémoire. WSDL n offre aucune information concernant le comportement même du service web, qui permettrait de répondre aux questions : Doit-on appeler l opération «OP 1» avant l opération «OP 2»? peut-on utiliser indifféremment l opération «annuler» et l opération «terminer»? Donc, pour permettre la réutilisation des services web dans le cadre de la composition, des informations supplémentaires sont obligatoires. Pour pallier au manque d information lié à l utilisation du langage de description WSDL, plusieurs langages de composition des services web ont été proposés tels que : BPEL [9], WSCI [10], etc. Cependant, l analyse formelle de ces langages n est pas possible à cause de leur manque de formalisme. Pour remédier à ce problème, il est nécessaire d avoir une méthode qui permet d analyser les services web avant leurs mises en œuvre, dans le but de fournir et de créer des services web corrects. Dans ce cas, les méthodes formelles apparaissent comme la solution la plus adéquate. 3. Contributions Dans ce travail, nous avons proposé une approche dirigée par les modèles pour la modélisation, la composition et la vérification formelle des services web. Pour parvenir à cet objectif : Dans un premier temps, nous nous sommes intéressés à la technologie des services web en dressant un état de l art des différents concepts qu elle englobe. Ce qui nous a permis d adopter un formalisme de modélisation adéquat à la nature même des services web, à savoir le formalisme «G-Nets» [11] qui est une classe de réseaux de Petri de haut-niveau (réseaux de Petri orientés objet). Dans un deuxième temps, nous nous sommes intéressés à la composition des services web où nous avons proposé une algèbre permettant de combiner des services web modélisés par des G-Nets pour élaborer d autres services plus complexes. L'algèbre proposée fournit un ensemble représentatif d opérateurs présentés par le biais de leur syntaxe et de leur sémantique. Dans un autre temps, nous avons axé notre étude sur les moyens de vérification des services web modélisés par des G-Nets. Dans cette optique, nous avons utilisé une technique permettant de transformer les modèles G-Nets vers des modèles PrT-Nets [4]

18 «Introduction générale» (réseaux de Petri Prédicats/Transitions) [12] équivalents dans le but d appliquer les techniques d'analyse formelle des PrT-Nets sur les spécifications G-Nets. Nous avons proposé également une autre approche de transformation qui permet de translater un modèle G-Net à une spécification Maude [13, 14] équivalente. L objectif de cette transformation est de bénéficier des différents outils de simulation et de vérification basés Maude. Enfin, pour automatiser notre approche, nous avons opté pour un langage de programmation orienté objet, afin de tirer profit des avantages de cette approche de programmation, en particulier la modularité, la réutilisation et la possibilité d extension du système. Par conséquent, nous avons choisi le langage «java» et l environnement «Eclipse» pour l implémentation de notre outil. 4. Organisation du document 4.1 Vue globale Ce document est constitué de deux parties principales : La partie «Etat de l art» : elle introduit le contexte dans lequel se place cette thèse, elle est organisée en trois chapitres : Chapitre 1 : «Les services web». Chapitre 2 : «L ingénierie dirigée par les modèles». Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture». La partie «Contribution» : elle concerne notre approche proposée, elle est organisée en deux chapitres : Chapitre 4 : «Une approche intégrée G-Nets/Maude pour la modélisation, la composition et la vérification des services web». Chapitre 5 : «Implémentation et étude de cas». 4.2 Contenu des chapitres Chapitre 1 : Dans ce chapitre, nous introduisons des définitions générales du concept «service web». Nous y présentons leur origine, une architecture de référence ainsi que les langages et protocoles utilisés pour leur déploiement. Nous abordons également le sujet de la composition des services web. Enfin, nous présentons un aperçu sur les différentes approches de modélisation et de composition des services web proposées dans la littérature. [5]

19 «Introduction générale» Chapitre 2 : Dans ce chapitre, nous présentons les concepts de base de l Ingénierie Dirigée par les Modèles (IDM) avec ses différentes variantes, nous nous intéressons en particulier à l Architecture Dirigée par les Modèles (ADM) dans le cadre des systèmes complexes. Chapitre 3 : Ce chapitre est consacré à la présentation des concepts de base des formalismes utilisés dans notre travail. Il s agit des réseaux de Petri (tout particulièrement les G-Nets) ainsi que de la logique de réécriture et son langage Maude. Chapitre 4 : Dans ce chapitre, nous proposons une approche dirigée par les modèles qui permet la spécification, la composition et la vérification formelle des services web. Nous commençons d abord par la phase de la modélisation. Après quoi, nous définissons une algèbre qui résout avec succès la composition complexe des services web. Enfin, nous abordons le sujet de la vérification formelle des services web. Chapitre 5 : Ce chapitre est consacré à la mise en œuvre de notre approche. Nous proposons également une étude de cas où nous utilisons notre outil pour permettre de bien illustrer l approche de modélisation, de composition et de vérification formelle des services web. Enfin nous terminerons par une conclusion générale qui donnera un aperçu du travail que nous avons accompli. Nous y discuterons également de quelques perspectives de notre travail. [6]

20 Chapitre 1 Les Services Web

21 Chapitre 1 : «Les Services Web» 1. Introduction Au début de l année 2000, le paradigme SOA a vu le jour dans le but de résoudre les problématiques d interopérabilité entre les différentes technologies informatiques distribuées utilisées en entreprise. Ce paradigme est l un des modèles les plus prometteurs, en effet il adopte les avantages des autres paradigmes (orienté objet et orienté composant), tels que la modularité et l encapsulation, et ajoute d autres concepts, à savoir le couplage faible et l interopérabilité [15]. Plusieurs concrétisations de l architecture orientée service ont été mises en place (OSGI [16], services web [6], etc.). Dans notre travail, nous nous intéressons uniquement aux services web qui représentent la réalisation la plus répandue. En plus du respect des principes du SOA, les services web présentent plusieurs avantages tels que l adaptation aux caractéristiques du web, et le bénéfice d un large support de la part des industriels. Dans ce chapitre, nous allons présenter quelques concepts de base qui entourent la technologie des services web. Nous présenterons la pile des technologies des Services web, ceci en mettant en relief la multitude de standards et de technologies existants. Après quoi nous allons aborder le sujet de la composition, et avant de conclure, nous donnerons d abord un aperçu sur les différentes approches de modélisation et de composition des services web existantes dans la littérature. 2. Définition Depuis les dernières années, l'utilisation de Services web a connu une popularité grandissante. Ces services sont très utilisés notamment par les entreprises pour rendre accessible leurs métiers ou leurs données via le web. Les services web ont été proposés initialement par IBM et Microsoft, puis en partie standardisés par le W3C (le consortium du World Wide Web). Plusieurs définitions des services web ont été proposées dans la littérature : D un point de vue technique, un service Web est une entité logicielle offrant une ou plusieurs fonctionnalités allant des plus simples aux plus complexes. Ces entités sont publiées, découvertes et invoquées à travers le web grâce à l'utilisation d'internet comme [7]

22 Chapitre 1 : «Les Services Web» infrastructure de communication ainsi que de formats de données standardisés comme XML [17]. Cette définition met en évidence uniquement le standard XML, donc n importe quelle application orientée Internet qui garantit ces caractéristiques et qui utilise les technologies basées sur XML est aussi un Service web. Selon IBM 1 : «Les services web sont la nouvelle vague des applications web. Ce sont des applications modulaires, auto-contenues et auto-descriptives qui peuvent être publiées, localisées et invoquées depuis le web. Les services web effectuent des actions allant de simples requêtes à des processus métiers complexes. Une fois qu un service web est déployé, d autres applications (y compris des services web) peuvent le découvrir et l invoquer». Les deux premières définitions affirment que les services web sont accessibles par d autres à travers le web en utilisant des protocoles et des formats standards, mais elles ne mettent pas en évidence les technologies utilisées pour mettre en œuvre un service web. Selon le W3C 2 : «Un service web est un système logiciel identifié par une URI et conçu pour supporter l interaction interopérable de machine à machine sur un réseau. Il possède une interface décrite dans un format exploitable par la machine, c.à.d. décrite en WSDL (web Services Description Language). D autres systèmes interagissent avec le service web d une façon prescrite par sa description en utilisant des messages SOAP (Simple Object Access Protocol), typiquement en utilisant HTTP (HyperText Transfer Protocol) avec une sérialisation XML en même temps que d autres normes du Web». Cette définition met l accent sur les standards de l Internet et l interface ouverte qui permet les invocations des services. Cependant, elle n est pas encore suffisamment précise parce qu elle ne mentionne pas la découverte de services web (UDDI). Une définition plus raffinée des services web est fournie par le dictionnaire Webopedia 3 qui définit un service web comme «une manière standardisée d intégration des applications 1 IBM Web services tutorial. Online: [8]

23 Chapitre 1 : «Les Services Web» basées sur le Web en utilisant les standards ouverts XML, SOAP, WSDL, UDDI et les protocoles de transport de l Internet. XML est utilisé pour représenter les données, SOAP pour transporter les données, WSDL pour décrire les services disponibles, et UDDI pour lister les fournisseurs de services et les services disponibles». 3. Architecture des services web Dans cette section, nous allons présenter l architecture de base des services web tel que proposée par IBM. Cette architecture comporte trois entités: le fournisseur de service, l annuaire de services et le client ou utilisateur du service (voir la figure 1.1). Le Fournisseur du service : qui publie son service en fournissant la description au format WSDL dans l annuaire de services et réalise les opérations propres au service. C est donc le propriétaire du service web. Il représente l environnement d'hébergement et d'exécution du service. Il est constitué de trois couches de bases : La couche de données : contient les différentes bases de données utilisées par le service. La couche applicative : c'est la plateforme de développement qui assure l'exécution du service web. La couche de description : elle expose les fonctionnalités du service via un fichier WSDL. L Annuaire: qui, d une part reçoit et enregistre les descriptions de services publiées par les fournisseurs, et d autre part reçoit et répond aux recherches de services lancées par les clients. C est donc un registre de description qui offre aux fournisseurs le moyen de publier et d'indexer leurs services web sur le réseau. Il permet également aux clients de rechercher ces services selon plusieurs critères. Le Client : qui obtient la description du service grâce à l annuaire et utilise le service. Dans l'architecture des services web, le Client est défini comme le consommateur du service. Il peut accéder à ce dernier en échangeant avec le fournisseur des messages SOAP. Cet échange de messages se fait généralement à l aide des protocoles Internet standards tels que HTTP, SMTP, etc. Techniquement, le Client peut être une simple application Windows ou web, comme il peut être un autre service web. [9]

24 Chapitre 1 : «Les Services Web» Par conséquent, un service web est toujours accompagné d'une description fournissant aux applications les informations nécessaires à son utilisation. Les services sont implantés par les fournisseurs qui mettent à disposition les descriptions de services sous forme de fichiers WSDL. Ces descriptions sont centralisées et stockées dans des annuaires. La notion d'annuaire est comparable aux annuaires téléphoniques que nous utilisons pour accéder à des personnes ou des services. Les applications clientes envoient des requêtes aux annuaires pour sélectionner les services, de la même manière que nous recherchons un numéro dans un annuaire téléphonique. Elles téléchargent ensuite les descriptions des services sélectionnés, et les invoquent directement. Localisation du service Client Annuaire UDDI Récupération de la description WSDL Interaction Publication de la description au format WSDL Fournisseur de services Service Web SOAP HTTP, SMTP, FTP, etc Figure 1.1 : Architecture de base des services web 4. Langages et protocoles utilisés par les services web L architecture fonctionnelle des services web que nous avons présenté précédemment montre l utilisation de nombreux langages et protocoles durant le déploiement et l invocation des services web. L'atout principal des protocoles SOAP et UDDI ainsi que du langage WSDL est de se reposer sur le langage XML (extensible Markup Language). Cette même architecture montre aussi que les services web se basent sur l utilisation des normes actuelles d'internet comme le protocole HTTP. [10]

25 Sécurité Transaction Chapitre 1 : «Les Services Web» Dans cette section, nous allons présenter d abord le langage XML. Après quoi nous définirons les déférentes couches horizontales illustrées dans la figure 1.2 qui décrit la pile de langages, de protocoles et de modèles des services web. Il est à noter que les couches verticales présentées dans cette même figure sortent du cadre de cette thèse. Mécanismes fonctionnels Mécanismes non fonctionnels Découverte / Publication (UDDI) Description (WSDL) Communication (SOAP) Transport (HTTP, SMTP ) Figure 1.2 : La pile Protocolaire simplifiée des services web. 4.1 Le langage XML (extensible Markup Language) Le langage XML standardisé par le W3C en 1998 est aujourd'hui largement reconnu et utilisé par de nombreuses entreprises comme format universel d'échange de données. XML est un métalangage de représentation de données. Il définit un ensemble de règles de formatage pour composer des données valides. XML constitue la technologie de base des architectures Web services ; c est un facteur important pour contourner les barrières techniques. XML est un standard qui permet de décrire des documents structurés transportables sur les protocoles d Internet. En effet, il apporte à l architecture des services web l extensibilité et la neutralité vis à vis des plateformes et des langages de développement [18]. De plus, grâce à la structuration, XML permet la distinction entre les données des applications et les données des protocoles. [11]

26 Chapitre 1 : «Les Services Web» La technologie des services web a été conçue pour fonctionner dans des environnements totalement hétérogènes. Cependant, l interopérabilité entre les systèmes hétérogènes demande des mécanismes puissants de correspondance et de gestion des types de données des messages entre les différents participants (clients et fournisseurs). C est une tâche où les schémas de type de données XML s avèrent bien adaptés. C est pour cette raison que la technologie des services web est essentiellement basée sur XML ainsi que les différentes spécifications qui tournent autour (les espaces de nom, les schémas XML, et les schémas de Type) [19]. Parmi les spécifications XML, nous soulignons : XSD (XML Schema) : c est un langage qui sert à décrire formellement un vocabulaire [20]. XSLT (Extensible Stylesheet Language Transformations) : est utilisé pour transformer un document XML basé sur un certain schéma en un autre document XML qui peut être un document lui-même basé sur un autre schéma [21]. XPath (XML Path Language) : fournit une syntaxe d expressions utilisées pour créer des chemins de localisation [22]. 4.2 La couche de Transport Cette couche s intéresse aux protocoles de transport de bas niveau, ces derniers vont transporter les requêtes et les réponses échangées entre services. Le protocole le plus utilisé et recommandé par le consortium WS-I (Web Service Interoperability) est l HTTP, mais d autres implémentations peuvent utiliser un autre ensemble de protocoles tels que : FTP, JMS (java messagerie services), SMTP, etc. 4.3 La couche de Communication (SOAP) Cette couche spécifie les protocoles d échanges de documents XML entre le service web et ses clients, elle caractérise aussi le mode d échange (s il est bloquant ou non). Le protocole SOAP est adopté comme un standard pour la messagerie entre les services web. SOAP SOAP (Simple Object Access Protocol) [8] est un protocole d échange de message indépendant des plateformes, c est un produit de Microsoft et IBM. [12]

27 Chapitre 1 : «Les Services Web» La première version de SOAP a été acceptée par le W3C (Word Wide Web Consortium) en SOAP est constitué de deux parties : une enveloppe XML, et un entête d un protocole de transport. La spécification du protocole SOAP ne donne aucune indication sur le mécanisme de transport du message. SOAP fait une séparation entre le message (C.à.d. le document XML) et le moyen de transport utilisé. Actuellement, SOAP utilise des protocoles tels que : HTTP ou SMT pour assurer le transport. L enveloppe XML contient à son tour trois sous éléments : L entête «Header»: est optionnel, il peut contenir des informations de sécurité (telles que les signatures électroniques), des informations transactionnelles, des informations de traçabilités, etc. L élément «Body»: est obligatoire, il contient les éléments suivants : Soit le nom de méthode, avec les données correspondantes, ou un simple document XML, pour le cas d une requête. Soit les valeurs de retour pour le cas d une réponse. L élément «Fault»: est optionnel, il fournit des informations sur d éventuelles erreurs survenues lors de l analyse du message. La figure 1.3 représente le format standard d un message SOAP. Message SOAP Entête du protocole de transport Message SOAP complet Enveloppe SOAP Entête SOAP Descripteurs facultatifs Corps SOAP Faute Champ optionnel Figure 1.3 : Schéma d un message SOAP [13]

28 Chapitre 1 : «Les Services Web» 4.4 La couche de Description (WSDL) WSDL (Web Service Description Language) [7] est un standard du W3C qui permet de définir la structure abstraite et concrète d un service. C est un document XML qui décrit la signature des opérations offertes par le service (nom d opérations, noms et types des paramètres d entrées/sorties), il définit aussi des liaisons concrètes pour ces opérations telles que le protocole de transport, l URI du service, le style du service, et les règles d encodage employées pour les paramètres d entrées/sorties. Nous notons que cette interface décrit juste la structure du service (la partie quoi) et non pas le comportement (la partie comment). Le document WSDL comporte six éléments: <definitions>, <types>, <message>, <porttype>, <binding> et <service>. La figure 1.4 offre une représentation concise de la spécification WSDL. <definitions> <types> Partie abstraite <message> <porttype> <operation> <binding> Partie concrète <service> <port> Figure 1.4 : Structure d une description WSDL 1.1 [14]

29 Chapitre 1 : «Les Services Web» <definitions> : L'élément «définitions» représente la racine du document WSDL. Il définit le nom du service web, déclare les différents espaces de nommage utilisés dans le reste du document, et contient tous les éléments qui décrivent le service web. <types> : L'élément «types» décrit tous les types de données complexes utilisés entre le client et le serveur. WSDL n'est pas exclusivement lié à un système de typage spécifique, mais il utilise la spécification W3C XML Schéma comme choix par défaut. Si le service utilise uniquement des types simples, tels que les chaînes de caractères et les entiers, l'élément types n'est pas requis. <message> : L élément «message» décrit les messages échangés par le service (les messages entrants et sortants). Il est composé d'un ou plusieurs éléments nommés <part>. ces derniers peuvent faire référence à des paramètres d'entrée ou à des valeurs de retour. <porttype> : L élément «porttype» représente une collection d'opérations. Une <operation> est une action abstraite accomplie par le service. Elle peut contenir éventuellement les sous éléments <input> et /ou <output> décrivant respectivement le message d entrée et le message de sortie. La spécification WSDL décrit quatre types d'opérations: Opération à sens unique (One-way) : Le service reçoit un message. L'opération a donc un seul élément <input>. Opération de type requête réponse (Request-response): Le service reçoit un message et envoie une réponse. L'opération a donc un élément <input>, suivi d'un élément <output>. Pour encapsuler des erreurs, un élément optionnel <fault> peut également être spécifié. Opération de type réponse sollicitée (Solicit-response): Le service envoie un message et reçoit une réponse. L'opération a donc un élément <output>, suivi d'un élément <input>. Pour encapsuler des erreurs, un élément optionnel <fault> peut également être spécifié. Opération de type notification (Notification): Le service envoie un message. L'opération a donc un seul élément <output>. [15]

30 Chapitre 1 : «Les Services Web» <binding> : L élément «binding» associe un porttype avec des informations concrètes telles que le protocole de transport (http, ftp ), les règles d encodage de données, et le style du service (RPC ou DOC). le style RPC impose un format précis aux messages SOAP (c.à.d. le nom de la méthode et les arguments pour la requête, et la valeur de retour pour la réponse). Ce style est adapté aux échanges synchrones. Le style DOC autorise n importe quel document XML bien formé comme requête ou réponse. Ce style est adapté aux échanges asynchrones. <service> : L élément «service» est constitué d un ensemble de <port>. Un <port> est une association entre un <binding> et un point d accès (c.à.d. l url) qui indique l adresse du service web. Nous pouvons avoir plusieurs ports par services, (un même binding et des URLs différents, ou des «binding» différents et éventuellement des URLs différents). En plus de ces six principaux éléments, la spécification WSDL définit également les éléments facultatifs suivants: <documentation> : L'élément «documentation» est utilisé pour fournir des informations lisibles par l utilisateur (par exemple : description textuelle du service en utilisant le langage naturel). Il peut être inclus à l'intérieur de n'importe quel autre élément WSDL. <import> : L'élément «import» est utilisé pour importer d'autres documents WSDL ou des schémas XML. Par exemple, deux documents WSDL peuvent importer les mêmes éléments de base et encore inclure leurs propres éléments pour assurer le même service sur deux adresses physiques différentes. Il est à noter que cette fonctionnalité n est pas supportée par tous les outils WSDL pour l'instant. Pour plus d illustration, la figure 1.5 représente la description WSDL du service simple «HelloService». Ce dernier offre une fonction (opération) appelée «sayhello». La fonction reçoit un message «SayHelloRequest» avec une chaine de caractères représentant le paramètre d entrée, et retourne un message «SayHelloResponse» qui contient une autre chaine de caractères. Par exemple, si vous passez le mot «world» comme paramètre, le service renvoie le message d'accueil, «Hello, world!». [16]

31 Chapitre 1 : «Les Services Web» <?xml version="1.0" encoding="utf-8"?> <definitions name="helloservice" targetnamespace=" xmlns=" xmlns:soap=" xmlns:tns=" xmlns:xsd=" <message name="sayhellorequest"> <part name="firstname" type="xsd:string"/> </message> <message name="sayhelloresponse"> <part name="greeting" type="xsd:string"/> </message> <porttype name="hello_porttype"> <operation name="sayhello"> <input message="tns:sayhellorequest"/> <output message="tns:sayhelloresponse"/> </operation> </porttype> <binding name="hello_binding" type="tns:hello_porttype"> <soap:binding style="rpc" transport=" <operation name="sayhello"> <soap:operation soapaction="sayhello"/> <input> <soap:body encodingstyle=" namespace="urn:examples:helloservice" use="encoded"/> </input> <output> <soap:body encodingstyle=" namespace="urn:examples:helloservice" use="encoded"/> </output> </operation> </binding> <service name="hello_service"> <documentation>wsdl File for HelloService</documentation> <port binding="tns:hello_binding" name="hello_port"> <soap:address location=" </port> </service> </definitions> Figure 1.5 : Exemple d un document WSDL [23] [17]

32 Chapitre 1 : «Les Services Web» La version 1.0 de l interface WSDL a été créée en 2000 par IBM, Microsoft et Ariba, ensuite le consortium W3C a publié la version WSDL 1.1 en mars 2001 comme une note [7]. En juin 2007, la version WSDL 2.0 a été créée comme une recommandation W3C (C.à.d. norme). WSDL 2.0 a apporté quelques changements à la version WSDL 1.1, ils sont résumés comme suit : <porttype> est devenu <interface>. <port> est remplacé par <endpoints>. <message> est supprimé et l élément <xs :element> est utilisé pour spécifier les données échangées. 4.5 La couche de Découverte et de Publication (UDDI) UDDI (Universal Description, Discovery and Integration) [6] est une spécification d annuaires de services web, cette norme W3C propose un ensemble de structures à publier par les fournisseurs de services. Ces structures sont formalisées en XML, elles proposent 03 types d informations (voir la figure 1.6) : Les pages blanches : qui décrivent les informations de contacts sur les entreprises. Les pages jaunes : qui décrivent des informations de classification de services. Les pages vertes : qui donnent des informations techniques des services. UDDI Pages blanches (Noms, adresses, contacts des entreprises enregistrées, etc.) Pages jaunes (Classification des entreprises et des services par secteurs d'activité) Pages vertes (Informations techniques sur les services proposés) Figure 1.6 : Le contenu de l annuaire UDDI [18]

33 Chapitre 1 : «Les Services Web» La norme UDDI offre aussi une API aux applications clientes, pour rechercher des services et/ou ses fournisseurs, ajouter ou modifier des services ou des entreprises. Nous distinguons deux types d annuaires UDDI (publiques et privés) : L annuaire UDDI publique est implémenté sous forme d un réseau de nœuds UDDI, ces nœuds sont synchronisés, chacun d eux est possédé par une entreprise donnée (telles que SAP, IBM et Microsoft). La publication d un service chez une entreprise Propage automatiquement ses informations (pages blanches, jaunes et vertes) aux différents nœuds UDDI. L accès à l ensemble des informations des registres peut se faire à n importe quel nœud UDDI. Ce type d annuaire est gratuit. L annuaire UDDI privé permet à une entreprise de choisir les partenaires pour lesquels elle autorise la publication et l'invocation de ses services web. Les structures de données d'un UDDI sont illustrées dans la figure 1.7. Business Entity TModel Business Service Publisher Assertion Binding Template Figure 1.7 : Les structures de données d UDDI. La partie «pages blanches» : est constituée de deux éléments <businessentity> et <publisherassertion>. <businessentity> donne des informations de contact sur l organisation fournissant les services (les noms des dirigeants, les s, les numéros de téléphones, le site web, etc.). <publisherassertion> spécifie les liens d affiliation entre deux entreprises (mère et fille). Lorsque deux éléments <businessentity> référencent la même <publisherassertion>, nous parlons de relation d affiliation entre ces <businessentity>. [19]

34 Chapitre 1 : «Les Services Web» La partie «pages jaunes» : est constituée des éléments <businessservice>. <businessservice> décrit un ensemble de services fournis par une organisation (le nom du service, la description textuelle, les informations de classification). Un <businessservice> est un sous élément de <businessentity>. La partie «pages vertes» : est constituée des éléments <bindingtemplate> et <tmodel>. <bindingtemplate> spécifie des informations techniques, telles que l URI du service. Un <bindingtemplate> est un sous élément de <businessservice>. <tmodel> définit des structures d informations techniques telles que l interface WSDL, les taxonomies industrielles, les ontologies, etc. Un élément <tmodel> peut être réutilisé par plusieurs éléments <bindingtemplate>. Le protocole d'utilisation de l'uddi offre trois fonctions de base : Publish : permet de publier un nouveau service. find : permet d'interroger l'annuaire UDDI. bind : permet d'établir une connexion entre l'application cliente et le service. 5. Composition des Services Web Depuis les dernières années, l'utilisation de services web a connu une popularité grandissante. Ces services sont très utilisés notamment par les entreprises pour rendre accessible leurs métiers ou leurs données via le Web. Les services web, tels qu'ils sont présentés, sont conceptuellement limités à des fonctionnalités relativement simples qui sont modélisées par une collection d'opérations [24]. Toutefois, il est nécessaire de construire de nouvelles applications par composition de services afin de répondre à des exigences plus complexes. La composition de services web est considérée comme l une des motivations les plus importantes de cette technologie. Elle détient un potentiel énorme dans la réorganisation et l intégration des applications d'entreprise. Malheureusement, les technologies actuelles basées sur WSDL, UDDI et SOAP offrent des solutions pour la description, la publication, la découverte et l'interopérabilité des services web, mais ne permettent pas d effectuer leur composition qui reste une tache très complexe. [20]

35 Chapitre 1 : «Les Services Web» Dans cette section, nous présentons la composition des services web et ses concepts adjacents. 5.1 Définition Plusieurs définitions ont été proposées pour le concept de composition, nous citons dans ce qui suit les plus communes : «La composition des services web c est la capacité d offrir des services à valeur ajoutée en combinant des services existants probablement offerts par différentes organisations» [25]. Selon [26], la composition des services web peut être définie comme : «le processus de sélection, de combinaison et d'exécution de services en vue d'accomplir un objectif donné». Une autre définition plus raffinée est celle proposée par Georges Gardarin, qui définit la composition des services web comme étant : «une technique permettant d'assembler des services Web afin d'atteindre un objectif particulier, par l'intermédiaire de primitives de contrôle (boucle, test, traitement d'exception, etc.) et d'échange (envoi et réception de messages). Les services composants existent au préalable et peuvent ne pas être fournis par la même organisation» [27]. 5.2 Cycle de vie d une composition de services La composition de services peut être vue comme étant un moyen efficace pour créer, exécuter, et maintenir des services qui dépendent d autres [28]. Dans [29], Benatallah et al. ont défini un cycle de vie d une composition de services web englobant six activités. Ces dernières sont représentées dans la figure 1.8. L encapsulation de services natifs : Cette tâche garantit que tout service peut être appelé lors d une composition, (quel que soit son modèle de données, son protocole d interaction, etc.). L établissement d accord d externalisation : Cette tâche établir les obligations contractuelles entre les services partenaires. consiste à négocier et [21]

36 Chapitre 1 : «Les Services Web» Encapsulation des services natifs Contrôle de l exécution des services composites Exécution des services composants Evolutivité des services Assemblage des services composants Etablissement d accord d externalisation Figure 1.8 : Cycle de vie d une composition de services web L assemblage de services composants : Cette tâche consiste en l'identification des services réalisant une composition donnée tout en spécifiant leurs interactions à un haut niveau d'abstraction. Elle permet aussi de dériver les descriptions externes et les conventions (service level agreements) des services composites résultants. L exécution de services composants : Cette tâche permet d exécuter les spécifications de la composition satisfaisant certaines contraintes pratiques (l efficacité, la disponibilité, etc.). Le contrôle de l exécution de services composites : Cette étape permet la vérification de plusieurs aspects et propriétés, par exemple : elle contrôle l accès aux services, vérifie les changements de statut et les échanges de messages. Ceci permet la détection des erreurs (violations de contrats), de mesurer les performances des services appelés et de prédire des exceptions. L évolutivité des services : Cette étape assure l évolution de la composition, (c.à.d. la modification des services invoqués, utilisation de nouveaux services, prise en compte des retours de l activité de contrôle). [22]

37 Chapitre 1 : «Les Services Web» 5.3 Orchestration et Chorégraphie La composition des services web peut être décrite sous deux angles : l'orchestration ou la chorégraphie. L orchestration : D après Sonia Jamal [30] : «L'orchestration des services Web permet de définir l'arrangement et l'enchaînement de ces services selon un canevas bien défini. Elle décrit la manière par laquelle les services peuvent interagir ensemble tout en incluant l'ordre d'exécution des différentes interactions». La composition des services web, en utilisant la technique de l orchestration, se base sur l exécution d un procédé métier central. Ce dernier est lui-même un service web qui prend le contrôle de tous les services web impliqués dans le processus de la composition et coordonne l exécution des différentes opérations des services composants. Ces derniers n ont pas de connaissance (et n ont pas besoin de l avoir) d être mêlés dans une composition et de faire partie d un processus métier. Seulement le coordinateur de l orchestration a besoin de cette connaissance. Le principe de l'orchestration est illustré par la figure 1.9. Service Web 3 Service Web 1 Service Web 4 Service Coordinateur Service Web 2 Service Web 5 Interaction Figure 1.9 : Principe de l'orchestration des services Web. La chorégraphie : Dans [30], l auteur a mentionné : «La chorégraphie permet de tracer la séquence de messages échangés dans un contexte de composition de services web. Elle est typiquement liée à la description de conversations existantes entre les [23]

38 Chapitre 1 : «Les Services Web». services tout en impliquant plusieurs parties, incluant les clients, les fournisseurs et les partenaires». Contrairement à l orchestration, la chorégraphie offre une vision décentralisée de la composition (elle ne repose pas sur un procédé central pour gérer la composition). Chaque service web mêlé dans la chorégraphie connaît exactement quand ses opérations doivent être exécutées et avec qui l interaction doit avoir lieu [31]. Le principe de la chorégraphie est illustré par la Figure Service Web 1 Service Web 2 Service Web 3 Interaction Figure 1.10 : Principe de la chorégraphie des services web. L orchestration est la technique de composition des services web la plus utilisée. En effet, elle offre plusieurs avantages, parmi lesquels nous citons: La clarté : Le responsable de tout le processus métier est connu de façon exacte (le coordinateur). La facilité de mise en œuvre : L orchestration permet de faciliter le passage de la conception à l'implémentation. Elle propose l'utilisation de normes et de standards ouverts, ce qui permet aussi de réduire les couts de mise en œuvre. La flexibilité : Les services web peuvent être incorporés et/ou substitués sans soucis, parce qu ils n ont pas conscience d appartenir à un processus métier. Simplicité, etc. [24]

39 Chapitre 1 : «Les Services Web» 5.4 Les types de composition de services web Après avoir présenté les deux techniques de coordination des services web (Orchestration et Chorégraphie), nous allons présenter dans cette partie les différents types de la composition. Dans la littérature nous pouvons distinguer deux axes de classification de la composition des services web : Premier axe : En fonction du degré de participation de l utilisateur dans la définition du schéma de composition (Composition manuelle, semi-automatique ou automatique) [32]. Deuxième axe : Selon la nature du processus de la sélection des services web (sélection à priori ou non des services composants). Dans ce cas, nous distinguons deux catégories (Composition statique ou dynamique). Dans ce qui suit, nous allons présenter ces différents types de composition Composition manuelle, semi-automatique et automatique Composition manuelle : La composition manuelle est basée sur l'intervention de l utilisateur qui gère la composition sans l aide d outils dédiés. Donc c est à l utilisateur de programmer et d implémenter la composition. Composition semi-automatique : La composition semi-automatique est constituée comme un pas en avant en comparaison avec la composition manuelle. Elle fournit des suggestions sémantiques pour aider à la sélection des services web dans le processus de composition. Composition automatique : La composition automatique prend en charge tout le processus de composition sans qu aucune intervention de l utilisateur ne soit requise. Cependant, la composition automatique a été et sera toujours une tâche difficile à réaliser. Nous pouvons citer différentes sources de complexité : La difficulté de la composition en fonction de l'expressivité du modèle de services et l'objectif de la composition. Le grand nombre de services web sur le Web. La diversité des modèles de conception de services en raison des besoins de modélisation et/ou de la vision des développeurs. [25]

40 Chapitre 1 : «Les Services Web» Composition statique et composition dynamique Composition statique (off-line): La composition statique a lieu au moment de la conception d'une application. Ainsi, les composants concernés sont choisis, liés et assemblés avant d'être déployés [24]. Une telle composition est adaptée pour les environnements fermés où les composants n'évoluent pas souvent. Ce type de composition engendre des applications peu flexibles, parfois inappropriées avec les exigences des clients. Microsoft Biztalk 4 est l un des moteurs de composition statiques de services Web. Composition dynamique (on-line) : La composition dynamique a lieu au moment de l'exécution. Elle permet de créer de manière autonome des services complexes en combinant des composants à la volée en fonction des demandes de l'utilisateur et du contexte [33]. Elle évolue dans des environnements flexibles et ouverts où la sélection et la combinaison des composants sont effectuées à la demande. La technologie de la composition dynamique est généralement contestée par : Le grand nombre de services qui deviennent disponibles chaque jour. La nature volatile de services web (par exemple : ils peuvent disparaître, être modifiés ou être temporairement indisponibles). Le nombre sans cesse croissant de fournisseurs de services. 5.5 Langages de composition de services web De nombreux langages ont vu le jour pour tenter de solutionner le problème de la composition des services web. Ces langages décrivent les interactions entre différents fournisseurs de services web et leurs clients. WSCL (Web Service Conversation Language) [34] de HP et WSCI (Web Service Choregraphy Interface) [10] sont des langages associés à la chorégraphie, alors que XPDL [35], YAWL [36], Orc [37] et BPEL [9], sont associés à l orchestration. Dans ce qui suit, nous allons présenter BPEL, le langage le plus utilisé dans le domaine de la composition des services web Le Langage BPEL BPEL ou BPEL4WS est un langage issu de la fusion de deux langages prédécesseurs : 4 [26]

41 Chapitre 1 : «Les Services Web» WSFL 5 (Web Services Flow Language) et XLANG 6 (Web Services for Business Process Design). WS-BPEL 2.0 est devenu un standard OASIS en BPEL permet de modéliser les processus métiers en termes d orchestration, en décrivant le flux de données (les variables) et le flux de contrôle (les activités simples et composées, les partenaires, etc.), son but est de créer une fonctionnalité complexe qui réutilise les services existants. Il permet aussi de donner une vue centralisée de l exécution de la composition. Nous distinguons deux types de processus BPEL (abstrait et exécutable). Processus abstrait : Ce processus spécifie les messages échangés entre les différents services web composants sans indiquer le comportement de chacun d eux. Processus exécutable : Ce processus permet de spécifier l ordre d exécution des activités, les partenaires concernés, les messages échangés entre ces partenaires, et les mécanismes de gestion des erreurs potentielles. ce processus peut être exécuté au moyen d un engin d orchestration. <process> <partnerlinks> <variables> <correlationsets> <faulthandlers> <eventhandlers> Activities Figure 1.11 : Structure d un fichier BPEL. 5 Langage d'orchestration de services Web proposé par IBM. 6 Langage d'orchestration de services Web proposé par Microsoft. [27]

42 Chapitre 1 : «Les Services Web» Comme montré dans la figure 1.11, la spécification BPEL offre plusieurs éléments décrits comme suit : <process> : L élément «process» représente la racine du fichier BPEL. Il contient l attribut «name» qui permet de définir le nom du processus. <partnerlinks> : Il permet de spécifier les différents partenaires participant dans la composition. Il est composé d un ou plusieurs éléments <PartnerLink>. Ce dernier contient les attributs suivants : name : Le nom donné au partnerlink. myrole : Spécifie le rôle du processus BPEL. partnerrole : Spécifie le rôle du partenaire ou du client. partnerlinktype : Représente le type de partnerlink défini dans la description WSDL. Si l attribut «myrole» est uniquement utilisé (sans «partnerrole»), cela signifie que seules les interactions vers le processus sont autorisées. Dans le cas opposé (si l attribut «partnerrole» est uniquement utilisé sans «myrole»), seules les interactions vers les partenaires et les clients sont autorisées. Il est à noter que les deux attributs peuvent être utilisés en même temps. <variables> : Il permet de définir les différentes variables utilisées dans le processus BPEL. Ces dernières servent à stocker des données ou des messages échangés afin de les réutiliser ultérieurement. <correlationsets> : Une orchestration peut être exécutée plusieurs fois. Chaque exécution est nommée instance. Pour acheminer les données à une instance particulière, nous utilisons l élément <correlationsets>. <faulthandlers> : Il permet de gérer les exceptions au niveau du <catch>. <eventhandlers> : Il représente les événements pouvant survenir au cours de l'exécution. Il permet aussi d associer un traitement à chacun de ces évènements. Les activités: <receive> : C est une attente bloquante d un message entrant. <reply> : Elle retourne un message suite à une réception d un autre message (à l aide de la primitive <receive>). La combinaison receive-reply utilise une opération request-response d un porttype du processus. <invoke> : Elle permet l appel d un partenaire (service) en se basant sur une opération de type one way ou request-response. [28]

43 Chapitre 1 : «Les Services Web» <Assign> : Cette activité permet la mise à jour des variables. <Throw> : Elle permet d indiquer les erreurs et les exceptions survenues lors de l exécution du processus et de les envoyer au catch de fault handler. <Wait> : Elle permet de bloquer l exécution du processus pour une période donnée. <Empty> : C est l opération rien-faire, elle est utile pour la synchronisation. Ces activités de base peuvent être combinées pour définir un algorithme complexe spécifiant les étapes par lesquelles passe le processus en utilisant les activités structurées telles que : <Sequence> : Elle définit une suite d activités exécutées par ordre d apparition dans la séquence. <flow> : Elle définit des activités exécutées en parallèle. <switch> : Elle définit un branchement conditionnel. <if> : Elle représente un autre cas de branchement conditionnel. <while>: Elle modélise une boucle conditionnelle. <Pick> : Elle bloque une activité jusqu'à la réception d un message ou l expiration d une période de temps. De façon générale, un processus BPEL commence par une activité <receive> et se termine par une activité <reply>. Il est interprété par un moteur d'orchestration tels que : Oracle BPEL Process Manager 7, TIBCO Business Works 8, etc. 6. Approches de modélisation et de composition des services web La composition des services web est un sujet qui a suscité l attention des chercheurs qui tentent de fournir des modèles sémantiques rigoureux, des langages et des plateformes pour la proposition des résultats efficaces pour cette issue. Comme présenté précédemment, plusieurs langages de composition de services web ont été proposés au cours de ces dernières années. Il s agit malheureusement de langages textuels exécutables conçus pour satisfaire à la phase d implémentation d un service web composé et qui négligent de fait l étape de spécification qui est importante, car elle facilite la compréhension globale du système ainsi que la tâche de développement. De plus, l analyse formelle des langages proposés n est pas possible à cause de leur manque de formalisme. 7 http :// 8 http :// [29]

44 Chapitre 1 : «Les Services Web» Donc, il est indispensable d utiliser des techniques et des modèles permettant la spécification formelle de la composition de services web, dans le but de s assurer du bon fonctionnement des services avant de les implémenter. Différents formalismes, pour la modélisation et la spécification de la composition de services, ont été proposés. Nous pouvons citer : les automates, les diagrammes d activité UML, les algèbres de processus et les réseaux de Petri [38]. 6.1 Les automates Les automates sont des modèles très utilisés dans le domaine de la spécification formelle de systèmes complexes. Un automate est composé d un ensemble de nœuds représentant les états et un ensemble d arcs étiquetés décrivant les transitions entre les états. Pour modéliser la composition de service à l aide d un automate, nous assignons généralement un état à chaque invocation de service, un autre état pour indiquer la fin du déroulement (exécution) de ce service et un événement à chaque réponse. Plusieurs chercheurs ont proposé d utiliser les automates dans le domaine de la composition de services web. Parmi ces approches, le modèle Roman [39] qui est basé sur les automates à états finis (FSA), le modèle Colombo [40] qui est une extension du modèle Roman qui ajoute la prise en charge des données et de la communication basée sur l échange de messages. Dans [41] les auteurs ont proposé de modéliser les services web à l aide d automates alternants à états finis (AFA). Une autre approche nommée COCOA a été introduite dans [42], l idée principale de COCOA est de convertir les processus OWL-S [43] en FSA. Ceci permet de transformer la composition de services en un problème d analyse d automates. Toutes ces approches nécessitent une interaction avec le développeur pour fournir au préalable une spécification détaillée du service composé. Pour résoudre ce problème, dans [44] les auteurs proposent d utiliser des automates déterministes à états finis (DFSA). Dans cette approche, le développeur définit uniquement des contraintes d exactitude sur la composition. Le comportement du service composé est automatiquement synthétisé. Mitra et al. ont proposé d utiliser des automates à entrées/sorties (Input/output automata) pour la modélisation de la composition des services web dans [45]. L approche choisie dans [45] consiste à identifier toutes les compositions réalisables en utilisant les services importés, et à vérifier si une des compositions fournit la fonctionnalité désirée. Le problème de cette technique est que le calcul des compositions possibles est exponentiel par rapport au nombre de services à composer. Mitra et al. ont donc publié un deuxième article [46] pour améliorer [30]

45 Chapitre 1 : «Les Services Web» cet algorithme en utilisant une technique de la programmation logique. Dans [47], Díaz et al. Ont suggéré une technique permettant de translater les descriptions WS-CDL [48] vers des automates temporisés. Le but de cette transformation est d utiliser UPPAAL [49] pour simuler et vérifier le comportement du système. Pour valider leur approche, les auteurs ont présenté un exemple illustratif (un système de réservation de billets d'avion). Une transformation du BPEL vers ce même type d automates a été proposée par Qian et al. dans [50]. Les auteurs ont utilisé aussi UPPAAL pour des raisons de vérification formelle. Il est à noter que cette approche est incomplète, car elle ne prend en considération qu un sous-ensemble de BPEL. L inconvénient d utilisation des automates réside dans le fait que ces derniers ne permettent pas la modélisation direct du branchement multiple et de la synchronisation. Ceci est dû au fait que leur sémantique ne permet pas la modélisation de la concurrence. Malgré que dans [51] Yan et Dague ont proposé une solution pour ce problème, l idée est de modéliser chaque branche d exécution parallèle par un automate indépendant et de définir des événements de synchronisation afin de réaliser leur interconnexion, mais ceci nécessite malheureusement la duplication de l état d entrée et de celui de sortie dans chaque branche parallèle. 6.2 Les diagrammes d activité UML UML [52] est considéré de nos jours comme un standard pour la modélisation orientée objet des systèmes complexes. Les diagrammes UML sont divisés en trois catégories de classes: les diagrammes structurels modélisent l aspect statique du système à concevoir comme les diagrammes de classes ou les diagrammes d objets; les diagrammes comportementaux comme les diagrammes d activité ou les diagrammes d états-transitions; et les diagrammes d interaction (dynamiques) comme les diagrammes de séquence. L un des diagrammes les plus utilisé dans le domaine de la composition des services web est le diagramme d activité. Pour modéliser la composition à l aide de ce dernier, généralement l exécution d un service est représentée par une action. La transition vers cette action modélise l appel au service et celle en sortie indique la fin de l exécution du service en question. Dans [53] les auteurs présentent une approche pour la modélisation de processus métier à l aide du diagramme d activité, ils ont aussi discuté de la transformation des résultats obtenus en BPEL 1.0. Cette transformation a été implémentée et mise à jour pour qu elle puisse prendre en charge UML 2.0 dans [54], mais l inconvénient de cette implémentation réside [31]

46 Chapitre 1 : «Les Services Web» dans le fait qu elle est basée toujours sur BPEL 1.0. D autres auteurs ont présenté un travail basé sur l utilisation d UML 1.4 pour le développement de services Web composés en suivant les principes de MDA [55]. Cette même idée a été utilisée dans [56], ce travail est basé sur UML 2.0. Cependant les auteurs ont indiqué que le modèle n était pas assez expressif. Il faut noter aussi qu UML reste toujours un langage semi-formel. 6.3 Les algèbres de processus Les algèbres de processus sont des familles de langages formels permettant de modéliser les systèmes complexes, en particulier les systèmes distribués et concurrentiels. Plusieurs travaux de recherche ont utilisé ces formalismes pour la composition de services web, nous citons à titre d exemple : le travail de Camara et al. qui ont proposé une technique de formalisation basée sur CCS pour la chorégraphie de service web dans [57]. Liu et al. ont Utilisé l algèbre CCS pour la modélisation et la spécification des services web afin de raisonner sur les propriétés comportementales de la composition. Dans [58], la sémantique du langage d orchestration BPEL est cette fois-ci spécifiée en utilisant π-calcul, cependant, des parties de BPEL telle que la gestion des données, ne sont pas traitées dans ce travail, ce qui n est pas surprenant car π-calcul ne permet pas la manipulation de données. Afin de prendre en considération les échanges de données au cours des interactions et compositions dynamiques de services web, d autres travaux basés sur des algèbres plus avancées ont été suggérés. Dans [59], Andrea Ferrara a proposé une transformation bidirectionnelle pour passer du BPEL au LOTOS et vice versa. Cette translation inclut la gestion des exceptions et permet la vérification des propriétés temporelles. Dans [60], les auteurs ont utilisé aussi le langage LOTOS pour modéliser la composition de services web, avant de procéder à la vérification formelle à l aide de l outil CADP 9. Malgré que les algèbres de processus sont bien adaptées pour la description des systèmes complexes, leur notation textuelle les rend moins lisibles que les réseaux de Petri ou les systèmes à transition d états. 6.4 Les réseaux de Petri Les réseaux de Petri (RdP S ) [61] représentent un moyen de modélisation du comportement des systèmes dynamiques à événements discrets. Un des avantages clé de ces modèles est la façon naturelle dans laquelle de nombreux aspects fondamentaux, à savoir l aspect 9 [32]

47 Chapitre 1 : «Les Services Web» mathématique et l aspect conceptuel, des systèmes concurrents sont identifiés [62]. Leur aspect graphique facilite énormément la modélisation conceptuelle des différents systèmes. Les RdPs sont très populaires dans le domaine de gestion des processus métiers (BPM) en raison de la variété des processus de flux de contrôle qu ils peuvent modéliser [63, 64]. Pour démontrer l aptitude des réseaux de Petri à modéliser la composition des services web, une traduction rigoureuse de BPEL en réseaux de Petri a été présentée par les auteurs dans [65]. Cette translation couvre toutes les structures de contrôle et les actions de communication de BPEL. Les modèles obtenus ont été utilisés pour vérifier les processus BPEL par le biais de l outil WofBPEL [66]. Comme les travaux de [67], notre approche réalise la composition des services web en utilisant une algèbre basée sur les réseaux de Petri. Leur modèle est assez expressif, mais les types de données ne peuvent pas être distingués, car ils font usage de réseaux de Petri élémentaires. Au lieu de ces derniers, notre modèle utilise une sorte de réseaux de Petri de haut niveau appelés G-Nets. Dans ce formalisme les arcs peuvent être étiquetés par des constantes ou des variables spécifiant les paramètres de jetons. À l instar des arcs, des conditions peuvent être associées à des transitions. Ces conditions précisent pour quelle valeur des paramètres la transition est franchissable. En plus, le formalisme des G-Nets nous permet de définir des attributs qui peuvent être de différents types (entier, chaine de caractères, etc.). Par conséquent, dans notre proposition, les types de données peuvent être distingués. Les travaux de [68] traitent également ce problème par la modélisation des services web et de leur composition via des réseaux de Petri colorés [69]. Ces derniers ont été utilisés aussi dans [70, 71] pour modéliser et composer les services web. Les auteurs ont automatisé cette approche en utilisant l outil de transformation de graphe ATOM 3 [72]. Par rapport à [68, 70, 71], le principal avantage de notre approche est que le modèle nécessite moins d efforts lorsqu il s agit de modéliser des services complexes et produit des modèles plus réduits. Dans [73], les auteurs ont utilisé les réseaux de Petri temporisés [74] pour modéliser les flux de services Web et leur description WSDL. Ce modèle est conçu pour assister le développeur afin d assurer l exactitude de la spécification en termes de non-blocage et de terminaison correcte de la transaction. Une technique de modélisation de services web en utilisant les réseaux de Petri stochastiques généralisés (LGSPN) [75] a été proposée par Chemaa et al. dans [76]. Ces auteurs ont suggéré également une algèbre expressive permettant de combiner les différents services modélisés par des LGSPN S. Comme dans notre approche, la proposition de [77] est également basée sur la modélisation du processus de composition de services web par une sorte de réseaux de Petri [33]

48 Chapitre 1 : «Les Services Web» orientés objet. Cependant, notre approche est formellement définie, de plus elle est basée sur un formalisme bien fondé, à savoir les G-Nets. 7. Conclusion La vulgarisation de l'accès à Internet et le développement rapide des nouvelles technologies (telles que : e-business, B2B, etc.) ont permis l émergence des services web. Ces derniers fournissent une nouvelle manière de développer des applications conformes aux exigences de l internet. La technologie des services web a pour objectif d uniformiser la présentation des services offerts par une entreprise et d en rendre l accès transparent pour tout type de plateforme, au travers d un certain nombre de standards d interopérabilité. Dans ce chapitre, nous avons présenté de manière générale quelques concepts liés à la technologie des services web. Nous avons d abord présenté quelques définitions de ce concept. Nous avons également décrit l architecture fondamentale des services web ainsi que les langages et les protocoles de base permettant leur déploiement. Après quoi nous avons abordé le sujet de la composition de services web. Enfin, nous avons présenté un survol sur les différentes approches de modélisation et de composition des services web existantes dans la littérature. [34]

49 Chapitre 2 L ingénierie dirigée par les modèles

50 Chapitre 2 : «L ingénierie dirigée par les modèles» 1. Introduction Dernièrement, l'ingénierie Dirigée par les Modèles (IDM, ou MDE : Model Driven Engineering) est devenue largement utilisée pour le développement des applications complexes distribuées. Par l IDM, nous faisons référence à une approche de développement mettant à disposition un ensemble d outils et de langages pour la manipulation des modèles. Ces derniers sont une manière intuitive et naturelle permettant de représenter l état et le comportement d un système, quel que soit son degré de complexité et à chaque étape de son cycle de vie. L IDM exploite les modèles en les détaillant en fonction du besoin, jusqu à obtention d un ou plusieurs squelettes de codes générés de manière systématique. L'intérêt principal de cette approche réside dans le fait qu elle permet d élever la productivité du développement en séparant la «logique métier» des plateformes utilisées. Dans ce chapitre, nous allons présenter les concepts de base de l Ingénierie Dirigée par les Modèles qui couvre différentes disciplines dans lesquelles les modèles jouent un rôle principal. Nous nous intéresserons également à l Architecture Dirigée par les Modèles (ADM) et à son utilisation pour le développement des systèmes complexes. 2. Concepts fondamentaux de l ingénierie dirigée par les modèles Dans cette section, nous nous proposons de définir les concepts de base de l Ingénierie Dirigée par les Modèles afin d appréhender de manière optimale cette approche [78]. 2.1 Système Dans le cadre de l ingénierie dirigée par les modèles, nous parlons souvent du système, quel que soit sa nature (existant ou à réaliser). Un système est défini comme un ensemble organisé d entités collaborant de manière unitaire, et en interaction permanente, pour assurer une ou plusieurs fonctions. Dans les systèmes, on s intéresse surtout aux logiciels. Ces derniers doivent respecter certains critères de qualité tels que : La convivialité : Elle décrit la facilité d apprentissage, d utilisation, de préparation des données, d interprétation des erreurs et de rattrapage en cas d erreur d utilisation. La validité : Un logiciel doit assurer la conformité de ses fonctionnalités avec celles décrites dans le cahier des charges. La réutilisabilité : Un logiciel doit être apte à être réutilisé, partiellement ou dans son intégralité, pour le développement d'autres logiciels. [35]

51 Chapitre 2 : «L ingénierie dirigée par les modèles» La fiabilité : Un logiciel doit être capable de gérer correctement ses propres erreurs de fonctionnement en cours d'exécution. La transparence : Un logiciel doit avoir la faculté de masquer à l'utilisateur les détails inutiles à l'utilisation de ses fonctionnalités. L'intégrité : Un logiciel doit protéger son code et ses données et doit pouvoir gérer les autorisations d accès. La portabilité : Exprime la possibilité de compiler le code source et/ou d'exécuter le logiciel sur des plateformes différentes. L extensibilité : Un logiciel doit se laisser maintenir, c'est-à-dire supporter des éventuelles modifications de ses fonctionnalités ou une extension vers des fonctions qui lui seront demandées sans compromettre son intégrité et sa fiabilité. La vérifiabilité, L'autonomie, etc. 2.2 Point de vue La plupart des spécifications de systèmes complexes sont si vastes qu'aucun individu ne peut comprendre pleinement tous les aspects de ces spécifications. En outre, nous avons tous des intérêts différents dans un système donné et des raisons différentes pour examiner les caractéristiques du système. Par exemple, le chef d'entreprise posera des questions différentes de celles posées par le développeur à propos du système. Un point de vue représente une vision totale, sur un système, qui s intéresse à un aspect particulier. La norme RM-ODP (Reference Model of Open Distributed Processing) définit cinq points de vue [79] : Point de vue Entreprise (le Pourquoi) : Il se concentre sur l'objectif, le domaine et les politiques du système. Il décrit les besoins de l'entreprise et la manière de les satisfaire. Point de vue Information (le Quoi): Il se concentre sur les informations et leur traitement. Il exprime la sémantique de l application à l aide de structures de données, de fonctions les manipulant et de propriétés d intégrité sur ces données. Point de vue Traitement (le Comment) : Il se concentre sur la conception fonctionnelle de l application. Il décrit les fonctionnalités fournies par le système et sa décomposition fonctionnelle. Point de vue Ingénierie (le Où) : Il représente les plateformes support de l application. Il se concentre sur les mécanismes et les fonctions nécessaires pour soutenir les interactions entre les objets distribués dans le système. Il décrit les [36]

52 Chapitre 2 : «L ingénierie dirigée par les modèles» fonctions et services de base que doit fournir l infrastructure d exécution pour que l on puisse construire les mécanismes assurant l interopérabilité en environnement hétérogène. Point de vue Technologie (le Avec Quoi) : Il se concentre sur le choix de la technologie du système. Il décrit les technologies choisies pour fournir le traitement, les différentes fonctionnalités du système et la présentation des informations. 2.3 Architecture L architecture désigne la structure générale inhérente à un système informatique. Elle permet la spécification des différentes parties du système ainsi que leurs relations (les règles d interaction entre ces parties). La structure d'un système peut être représentée sous forme graphiques à l aide des organigrammes tels que : les diagrammes entité-relation, les diagrammes UML, etc. Le diagramme peut concerner un logiciel, un réseau informatique, un sous-système, etc. 2.4 Modèle Le modèle est une représentation simplifiée du système. Il permet de spécifier formellement les fonctions, la structure et/ou le comportement de ce système, dans un certain but. Un modèle est souvent représenté par des schémas et par des textes. Ces derniers peuvent être exprimés dans un langage de modélisation ou en langage naturel. 2.5 Application Une application est une sous-classification des logiciels qui permet d automatiser certaines fonctionnalités. Un système décrit une ou plusieurs application(s) supportée(s) par une ou plusieurs plateformes. 2.6 Plateforme Une plateforme est un élément crucial dans le développement des applications. Elle peut être définie simplement comme une base de travail à partir de laquelle on peut écrire, lire, développer et utiliser un ensemble d applications. Les plateformes peuvent supporter plusieurs technologies (tels que : J2EE, CORBA, etc.) et sont implémentées par plusieurs fournisseurs (tels que: WebLogic, WebSphere, etc.). [37]

53 Chapitre 2 : «L ingénierie dirigée par les modèles» L Ingénierie Dirigée par les Modèles repose sur trois formalisations (les modèles, les métamodèles et la transformation de modèles). Dans les sections suivantes nous présenterons ces trois concepts. 3. Modèles et formalismes de modélisation L Ingénierie Dirigée par les Modèles se focalise sur des modèles et comment ceux-ci peuvent être utilisés pour créer un système [80]. Selon le dictionnaire Hachette : «un modèle est ce qui est proposé à l imitation». Cette définition est assez générale. Celles qui suivent proviennent de la littérature technique de l informatique et donnent plus d information sur le terme modèle dans l informatique. «Un modèle est défini comme étant une abstraction d un système qui se substitue à ce dernier pour le simuler et analyser ses propriétés» [81]. Dans [82], Bézivin et Gerbé ont défini un modèle comme étant «une simplification d un système créé avec un but spécifique. Le modèle doit être capable de répondre aux demandes à la place du système étudié. Les réponses fournies par le modèle doivent être les mêmes que celles fournies par le système, à condition qu elles restent dans la limite du domaine défini par le but général du système». Dans la littérature, nous trouvons différentes définitions du terme modèle. Cependant, elles transmettent la même idée : imitation, représentation, simplification et abstraction d un système. En plus des caractéristiques liées à la qualité, comme la traçabilité des modifications, la maintenabilité, l incrémentabilité ou encore l évolutivité, un modèle doit avoir les propriétés suivantes [83]: Abstrait : Un modèle doit permettre de cacher certains détails inutiles à un moment donné de la conception. Compréhensible: Un modèle doit être facile à assimiler et à manipuler par tous les acteurs entrant dans l élaboration du système. Fidèle et précis : Un modèle doit représenter fidèlement les propriétés et les caractéristiques du système. Prédictif : Un modèle doit fournir assez d informations pour permettre de prédire les propriétés du système. Economique : Les coûts de construction et de tests sur le modèle doivent être limités et ne doivent pas dépasser les coûts de construction d un prototype du système. [38]

54 Chapitre 2 : «L ingénierie dirigée par les modèles» La création de modèles est faite en utilisant des langages bien définis. Ces derniers sont connus sous le nom de langages de modélisation. Un langage de modélisation est défini par : une syntaxe abstraite qui décrit les concepts de base du langage ; une syntaxe concrète qui définit le type de notation (graphique, textuelle ou mixte) ; et une sémantique pour permettre l interprétation des concepts par les acteurs et les machines. De plus, il est conçu dans un domaine limité et avec des buts spécifiques, de sorte que nous pouvons considérer l existence de plusieurs langages de modélisation, chacun étant adapté à un domaine spécifique [84]. Le langage conçu pour créer des modèles est souvent défini comme un méta-modèle. 4. Méta-modèles et méta-modélisation L ingénierie dirigée par les modèles préconise l utilisation d un mécanisme standard et abstrait pour définir des modèles. Ce mécanisme abstrait est dénoté par le terme méta-modèle. Dans la littérature, nous trouvons plusieurs définitions de méta-modèle. Selon Jean Marie Favre [85] «un méta-modèle est un modèle d un langage de modèles». Dans [86], les auteurs ont défini un méta-modèle comme étant «un modèle qui définit le langage pour exprimer un modèle». Méta-modèle Conforme à Représenté par Modèle Système Figure 2.1 : Relation entre système, modèle et méta-modèle De manière générale, un méta-modèle est le modèle qui sert à exprimer (modéliser) le langage d expression d un modèle, avec ses entités, ses relations et ses contraintes. À son tour, le méta-modèle est aussi spécifié dans un langage de méta-modélisation par le métaméta-modèle. Arrivé à ce niveau d abstraction méta-circulaire, le langage est assez puissant pour spécifier sa propre syntaxe abstraite. [39]

55 Chapitre 2 : «L ingénierie dirigée par les modèles» Enfin, la méta-modélisation est l'activité de construire des méta-modèles. Elle est très utilisée aussi dans le domaine de l'ingénierie des systèmes d information, et particulièrement dans l'ingénierie des modèles et des méthodes [87]. La relation entre le système, le modèle et le méta-modèle est représentée dans la figure Transformation de modèles L ingénierie dirigée par les modèles considère les opérations de transformations de modèles comme le moteur de développement, que ce soit pour l analyse, l optimisation ou la génération de code. La transformation de modèles consiste à générer, à partir d un ou de plusieurs modèles sources, un ou plusieurs modèles cibles du même système. Les modèles sont dans tous les cas conformes à leurs méta-modèles respectifs. Elle est gouvernée par un ensemble de règles utilisées par le moteur de transformation. Ce moteur prend en entrée le(s) modèle(s) source(s), exécute les règles de transformation et génère le(s) modèle(s) cible(s). La figure 2.2 illustre les principaux concepts impliqués dans le processus de la transformation de modèles. Méta-modèle source Conforme à Mapping Règles de transformation Méta-modèle cible Conforme à Exécute Modèle source Lit Produit Modèle cible Moteur de transformation Figure 2.2 : Concepts de base de la transformation de modèles [40]

56 Chapitre 2 : «L ingénierie dirigée par les modèles» 5.1 Types de transformations Un facteur important à prendre en considération dans les transformations de modèles est le niveau d abstraction. Selon ce facteur, nous pouvons distinguer trois types de transformations : Transformations horizontales : Ces transformations gardent le même niveau d abstraction en modifiant les représentations du modèle source (ajout, modification, suppression ou restructuration d informations). Transformations verticales : La source et la cible d une transformation verticale sont définies à différents niveaux d abstraction. Un raffinement fait référence à une transformation qui baisse le niveau d abstraction. Tandis qu une abstraction désigne une transformation qui élève le niveau d abstraction. Transformations obliques : Ces transformations sont généralement utilisées par les compilateurs qui optimisent le code source avant la génération du code exécutable. Elles sont le résultat de la combinaison des deux premiers types de transformations. Selon la nature des méta-modèles sources et cibles, nous distinguons deux types de transformations : Transformations endogènes : La transformation de modèles est qualifiée d endogène si les modèles sources et cibles sont conformes au même méta-modèle. Transformations exogènes : la transformation de modèles est dite exogène si elle se fait entre deux méta-modèles (source et cible) différents. 5.2 Classification des approches de transformation de modèles Selon la classification proposée par Czarnecki et Helsen [88], les transformations de modèles peuvent être partagées en deux grandes classes : les transformations «Modèle vers Modèle» et les transformations «Modèle vers Code». [41]

57 Chapitre 2 : «L ingénierie dirigée par les modèles» Transformation Modèle vers Modèle (M2M : Model-to-Model) Les transformations de type M2M consistent à transformer un modèle source en un modèle cible, ces modèles peuvent être des instances de différents méta-modèles. Elles offrent des transformations plus modulaires et faciles à maintenir, et permettent la génération de plusieurs modèles intermédiaires avant d atteindre le modèle final. Ces modèles intermédiaires peuvent être utiles pour étudier les différentes vues du système, son optimisation, la vérification de ses propriétés et sa validation. Nous pouvons distinguer cinq techniques de transformation M2M : Approche de manipulation directe : Cette approche est basée sur une représentation interne des modèles source et cible, en plus des API pour les manipuler. La combinaison JMI 1 (Java Metadata Interface) et Java sont souvent utilisées dans la mise en œuvre de cette approche. Approche relationnelle : Cette approche utilise les contraintes pour spécifier les relations entre les éléments du modèle source et ceux du modèle cible en utilisant une logique déclarative basée sur des relations mathématiques. L un des outils qui supportent cette technique de transformation est medini QVT 2. Approche basée sur les transformations de graphes : Cette approche convient lorsque les modèles sont représentés par des graphes. Elle exprime les transformations sous une forme déclarative. Les règles de transformation sont définies sur des parties de modèle et non pas sur des éléments basiques. Une opération de filtrage de motifs (Pattern Matching) est ensuite lancée. Le moteur de transformation compare à chaque fois des fragments du modèle source pour trouver des règles applicables. Ce fragment est ensuite remplacé par son équivalent dans la règle appliquée. Quelques exemples d outils permettant les transformations de graphes: VIATRA2 3, ATOM3 4, UMLX 5, etc http ://atom3.cs.mcgill.ca/ 5 [42]

58 Chapitre 2 : «L ingénierie dirigée par les modèles» Approche dirigée par la structure : Elle est divisée en deux étapes, la première se charge de la création d une structure hiérarchique du modèle cible, la seconde ajuste ses attributs et ses références. Le cadre de transformation fourni par l outil OptimalJ 6 est un exemple d une approche basée sur la structure. Approche hybride : Les approches hybrides représentent une combinaison des différentes techniques ou alors celle d approches utilisant à la fois des règles déclaratives et impératives. ATL 7 est un exemple de cette approche Transformation Modèle vers Code (M2T : Model-to-Text) Il existe deux techniques de transformations M2T : la première est basée sur le principe du visiteur, tandis que la deuxième est basée sur le principe de templates. Approche basée sur le visiteur (Visitor-based Approach): Elle consiste à fournir un mécanisme de visiteur pour traverser la représentation interne d un modèle et créer le code. On peut citer comme exemple le framework Jamda 8 qui fournit un ensemble de classes pour représenter les modèles UML, une API pour manipuler les modèles, et un mécanisme de visiteur pour générer le code [89]. Approche basée sur les templates (Template-based Approach): Dans cette approche, la structure d un template ressemble au code à générer. Au niveau du template, il n y a pas de séparation syntaxique entre la partie gauche d une règle de transformation (LHS) et la partie droite de la règle (RHS). le LHS utilise une logique exécutable pour accéder au modèle source, le RHS combine des patrons non typés et une logique exécutable (la logique : code ou requêtes déclaratives). Parmi les outils qui supportent cette technique, nous pouvons citer : JET 9 transformation modèle vers modèle). et OptimalJ (ce dernier fournit aussi la La figure 2.3 présente les deux classifications ainsi que les différentes techniques de transformation de modèles [43]

59 Chapitre 2 : «L ingénierie dirigée par les modèles» Les approches de transformation de modèles Modèle vers Modèle Modèle vers Code Manipulation directe Transformation de graphes Dirigée par la structure Relationnelle Hybride Basée sur le visiteur Basée sur les templates Figure 2.3 : Les approches de transformation de modèles 6. Manipulation des modèles Dans le domaine de l ingénierie dirigée par les modèles, nous pouvons trouver plusieurs activités liées à la manipulation des modèles. Chacune appartient à un contexte spécifique. Parmi ces activités nous pouvons citer: La réalisation des modèles : Une bonne maîtrise du langage utilisé dans la modélisation et une expertise technique sont nécessaires pour la réalisation des modèles. Plus les systèmes sont complexes, plus leurs modèles deviennent également complexes et surtout de taille importante. Dans ce cas, La qualité de l outillage devient alors essentielle car ce sont les outils qui permettent de mieux visualiser le modèle, de s affranchir de certains détails ou encore de vérifier automatiquement la syntaxe. Le stockage des modèles : Cette activité concerne les formats de stockage, l organisation du stockage et la gestion des métadonnées des modèles. L échange des modèles : Pour une bonne communication entre eux, les acteurs d un projet doivent procéder à l échange de leurs modèles. Ces derniers doivent être [44]

60 Chapitre 2 : «L ingénierie dirigée par les modèles» compréhensibles par tous, pour éviter tout risque pouvant exposer le système implémenté à des dégâts. L échange de modèles prend en considération les contraintes du format (sérialisation, transport, etc.), les contraintes de traduction ainsi que celles d interprétation de la sémantique pour leur interopérabilité. L interrogation des modèles : C est l activité permettant la recherche et la récupération des informations dans les modèles. L exécution des modèles : Cette activité comprend toutes les tâches réalisables à partir de la simulation du système jusqu à son exécution en temps-réel, en passant par l exécution symbolique et la génération du code. La vérification des modèles : La vérification d un modèle consiste à vérifier ses propriétés propres par rapport à ce que l on attend de lui. Cette vérification est syntaxique et sémantique. La vérification sémantique est la plus complexe. Il existe différentes techniques pour procéder à la vérification d un modèle. Nous citons: la technique de preuves qui s appuie sur les représentations formelles du système basées sur la logique, les automates, les réseaux de Petri, etc. Une autre technique est le «model-cheking» qui vise à analyser le comportement du système tout en vérifiant des propriétés telles que la sûreté, l atteignabilité ou la vivacité. chacune de ces techniques a ses avantages et ses inconvénients. Par exemple, la technique de «model-cheking» apporte avec elle un risque d explosion combinatoire du nombre d états dans le cas des systèmes complexes. La validation des modèles : La validation affirme ou non que le système implémenté répond aux besoins initiaux. Certaines techniques de tests sont utilisables pour la vérification mais également pour la validation. Les modèles génèrent des scénarios et des vecteurs de test de façon automatique [90]. La gestion de l évolution des modèles : Les modèles évoluent tout au long du cycle de développement du système. Ils peuvent être corrigés ou modifiés en ajoutant d autres fonctionnalités. Ces modifications sont automatiquement répercutées sur les autres modèles impliqués. [45]

61 Chapitre 2 : «L ingénierie dirigée par les modèles» 7. L architecture dirigée par les modèles (ADM) L ingénierie dirigée par les modèles est un domaine basé sur les modèles et les technologies liées à leurs manipulations. Pour la pratique, il existe plusieurs manières d utiliser les modèles dans le processus de développement d un système. L approche la plus développée et la plus utilisée est L Architecture Dirigée par les Modèles (MDA : Model Driven Architecture). 7.1 Définition L architecture dirigée par les modèles est une approche proposée par l OMG 10 (Object Management Group) en 2000 comme une réponse à l hétérogénéité des technologies utilisées dans le cadre du génie logiciel [91]. L approche ADM préconise l utilisation de plusieurs modèles indépendants des détails techniques de l implémentation. Cette méthode consiste en l élaboration et la transformation de modèles tout au long du processus de développement d un système. Ces modèles ont pour objectif de simplifier la gestion de la complexité des systèmes en spécifiant différents niveaux d abstraction, aussi bien pour la vue globale du système que pour les protocoles et les algorithmes. Ces modèles sont reliés par des liens de traçabilité et peuvent être exprimés de façon textuelle ou graphique. En résumé, l ADM est une démarche de développement basée sur les modèles et un ensemble de standards de l OMG. Cette démarche permet de séparer les spécifications fonctionnelles d un système des spécifications de son implémentation sur une plateforme donnée. Parmi les standards fondamentaux de l OMG liés à l ADM nous pouvons citer : UML (Unified Modeling Language) [52] : C est un langage visuel semi-formel pour la modélisation des systèmes. Il permet de schématiser l architecture, les solutions et les vues avec des diagrammes augmentés de texte. MOF (Meta-Object Facility) [92] : C est un standard de méta-modélisation constitué d un ensemble d interfaces standards pour définir la syntaxe et la sémantique d un langage de modélisation, créé principalement pour définir la notation UML [46]

62 Chapitre 2 : «L ingénierie dirigée par les modèles» OCL (Object Constraint Language) [93] : C est un langage qui, intégré à UML, lui permet de formaliser l expression des contraintes. XMI (XML Metadata Interchange) [94]: C est un standard d échange de métadonnées. CWM (Common Warehouse Metamodel) [95] : C est une interface basée sur UML, MOF et XMI pour faciliter l échange de métadonnées entre outils, plateformes et bibliothèques de métadonnées dans un environnement hétérogène. MOFM2T (MOF Model-to-Text language) [96] : C est une spécification utilisée pour exprimer des transformations de modèles en texte. QVT [97] : C est un langage standard pour exprimer les transformations de modèles. 7.2 Typologie des modèles dans l ADM L approche MDA permet la manipulation des modèles de natures diverses tels que : les modèles d'objets métiers, de processus, de service, de plateforme, etc. Nous pouvons distinguer quatre classes de modèles : Les modèles d exigences (CIM : Computation Independent Model) : La réalisation de ce modèle est la première étape dans le développement d un système puisqu elle va permettre de modéliser toutes les exigences du client et définir les différentes interactions qui impliqueront le système dans ses environnements, interne ou externe. De ce fait, le CIM sera considéré comme référence pour vérifier la conformité du système avec les exigences du client. Le CIM ne donne aucun détail sur la façon de la réalisation ou le fonctionnement du système mais exprime clairement des liens de traçabilité avec les modèles futurs. Les modèles d analyse et conception abstraite (PIM : Platform Independent Model) : Ces modèles doivent être indépendants de toute plateforme d implémentation mais aussi contenir assez de détails pour permettre la génération automatique du code. Ils organisent le futur système en modules et sous-modules et relient le premier modèle d exigence CIM avec le code. [47]

63 Chapitre 2 : «L ingénierie dirigée par les modèles» Les modèles de description de plateforme (PDM : Platform Description Platform) : Ces modèles fournissent l ensemble de concepts techniques liés à la plateforme d exécution et à ses services. Ils contiennent toutes les informations nécessaires à sa manipulation. Les modèles de code (PSM : Platform Specific Model) : Les modèles PSM facilitent la génération du code à partir de la combinaison des modèles PIM et PDM. Les PSM expriment, par exemple, les composants, les instructions, les conditions, etc Cycle de développement de l approche ADM Le cycle de développement de l approche ADM suit un processus en Y [98] dont les branches représentent les spécifications fonctionnelles du système et les spécifications techniques de la plateforme. L implémentation est la branche qui rassemble les deux spécifications comme le montre la figure 2.4. CIM PDM Branche fonctionnelle PIM Branche technique PSM Code Figure 2.4 : Le cycle de développement en Y L architecture dirigée par les modèles considère le processus de développement du système comme une suite successive et stratégique de transformations de modèles. Ces transformations établissent de manière automatique des liens de traçabilité entre les quatre types de modèles discutés précédemment. [48]

64 Chapitre 2 : «L ingénierie dirigée par les modèles» 7.4 L architecture à quatre niveaux L OMG a défini une architecture à quatre niveaux d'abstraction, comme cadre général pour l'intégration des méta-modèles, en se basant sur MOF. Cette architecture est représentée dans la figure 2.5. Méta-méta-modèle M3 MOF Méta-modèle Modèle Le monde réel M2 M1 M0 Le méta-modèle UML et autres méta-modèles Des modèles UML et d autres formalismes Différentes utilisations de ces modèles Figure 2.5 : Architecture à quatre niveaux Le niveau M0 (Le monde réel) : Il ne s agit pas d un niveau de modélisation proprement dit. Il contient les informations réelles de l utilisateur, c est une instance du modèle du niveau M1. Le niveau M1 (Modèle) : Le niveau M1 est composé de modèles d informations. Il décrit les informations de M0. Ce niveau contient les modèles UML, les PIM et les PSM. Les éléments d un modèle «M1» sont des instances des concepts décrits dans un méta-modèle «M2». Le niveau M2 (Méta-modèle): Il définit le langage de modélisation et la grammaire de représentation des modèles M1. Par exemple, ce niveau contient le méta-modèle UML qui définit la structure interne des modèles UML ainsi que les profils UML qui étendent le méta-modèle. Les concepts définis par un méta-modèle sont des instances des concepts du MOF. [49]

65 Chapitre 2 : «L ingénierie dirigée par les modèles» Le niveau M3 (Méta-méta-modèle): Ce niveau est composé d une seule entité réflexive (auto-descriptive) appelée le MOF. Cette dernière permet de décrire la structure des méta-modèles, d étendre ou de modifier les méta-modèles existants. 8. Transformation de graphes Les graphes représentent un moyen intuitif, pratique et direct pour la modélisation des systèmes complexes. Les réseaux de Petri, les automates et les diagrammes UML sont des exemples pratiques de graphes de modélisation. Pour spécifier l évolution des modèles, nous pouvons exploiter les techniques de transformation de graphes. Ces dernières ont évolué pour remédier au problème du manque d expressivité rencontré par les approches de réécriture classiques telles que les grammaires de Chomsky. Dans la suite de cette section, nous allons présenter d abord la notion de graphes ainsi que ces propriétés. Après quoi, nous présenterons les différents principes de la transformation de graphes. 8.1 Notion de graphe Il existe deux types de graphes: les graphes non-orientés et les digraphes Graphe non-orienté Un graphe est constitué d un ensemble de sommets (nœuds) dont certaines paires sont directement reliées par un ou plusieurs liens (arêtes). Plus formellement, un graphe où : est un ensemble de sommets. est un sous-ensemble de représentant les arêtes. Soit : Si : Nous disons que les deux sommets et sont adjacents. Si : Nous disons que est réflexif et est une boucle. L ordre d un graphe est le nombre de ses sommets sommet est le nombre de ses voisins. et le degré d un [50]

66 Chapitre 2 : «L ingénierie dirigée par les modèles» La figure 2.6 montre un exemple d'un graphe non-orienté (A). Ce dernier est constitué d un ensemble de sommets { } et un ensemble d'arêtes { }. Dans cet exemple, nous avons Figure 2.6 : Graphe non-orienté (A) Un sous-graphe d'un graphe G est un graphe G' composé de certains sommets de G, ainsi que de toutes les arêtes qui relient ces sommets. La figure 2.7 présente un exemple où le graphe (B) est un sous-graphe du graphe (A) (A) 5 4 (B) 5 Figure 2.7 : Graphe (A) et sous-graphe (B) Digraphe Un digraphe (graphe orienté) est un graphe dont les arêtes sont orientées : nous parlons alors de l'origine et de l'extrémité d'une arête. Dans ce cas, une arête est appelée«arc». La figure 2.8 illustre un exemple de graphe orienté. [51]

67 Chapitre 2 : «L ingénierie dirigée par les modèles» Figure 2.8 : Digraphe Un graphe étiqueté est un graphe orienté, dont les arcs sont munis d'étiquettes. Si toutes les étiquettes sont des nombres positifs, on parle de graphe pondéré. La figure 2.9 illustre un exemple de graphe orienté étiqueté. 2 a 1 1 a 3 4 a 2 3 a 6 a 4 a5 5 Figure 2.9 : Graphe orienté étiqueté Un graphe complet est un graphe simple dont tous les sommets sont adjacents les uns avec les autres. Un graphe attribué est un graphe qui peut contenir un ensemble prédéfini d attributs. 8.2 Grammaire de graphe Une grammaire de graphe [99] est généralement définie par un triplet GG = (P, S, T) Où : P : ensemble de règles. S : un graphe initial. T : ensemble de symboles. [52]

68 Chapitre 2 : «L ingénierie dirigée par les modèles» Une grammaire de graphes distingue les graphes non terminaux, qui sont les résultats intermédiaires sur lesquels les règles sont appliquées, des graphes terminaux dont on ne peut plus appliquer de règles. Ces derniers sont dans le langage engendré par la grammaire de graphe. Pour vérifier si un graphe G est dans les langages engendrés par une grammaire de graphe, il doit être analysé. Le processus d analyse va déterminer une séquence de règles dérivant G [100] Règle de transformation Une règle de transformation de graphe «R» est définie par un 6-uplet Où: R= (LHS, RHS, K, glue, emb, cond) LHS : C est le graphe de partie gauche. RHS : C est le graphe de partie droite. K : C est un sous graphe de LHS. glue : C est une occurrence de K dans RHS qui relie le sous graphe avec le graphe de partie droite. emb : C est une relation d enfoncement qui relie les sommets du graphe de la partie gauche et ceux du graphe de la partie droite. cond : C est un ensemble qui indique les conditions d application de la règle Système de transformation de graphe Un système de transformation de graphes [101] est un système de réécriture de graphe qui applique les règles de la grammaire de graphe sur son graphe initial de façon itérative et dans un ordre bien défini jusqu à ce que plus aucune règle ne soit plus applicable. L application d une règle R= (LHS, RHS, K, glue, emb, cond) à un graphe G produit comme résultat un graphe H en passant par les cinq étapes suivantes : Première étape : choisir une occurrence du graphe de partie gauche LHS dans G. Deuxième étape : Vérifier les conditions d application d après cond. Troisième étape : Retirer l occurrence LHS (jusqu à K) de G ainsi que les arcs pendillés (tous les arcs ayant perdu leurs sources et/ou leurs destinations). Ce qui fournit le graphe de contexte D de LHS qui a laissé une occurrence de K. [53]

69 Chapitre 2 : «L ingénierie dirigée par les modèles» LHS RHS K glue Choisir &Vérifier G H Supprimer Enfoncer D Coller Figure 2.10 : Les étapes d application d une règle de transformation Quatrième étape : Coller le graphe de contexte D et le graphe de partie droite RHS suivant l occurrence de K dans D et dans RHS, c est la construction de l union de disjonction de D et RHS, et pour chaque point dans K, identifier le point correspondant dans D avec le point correspondant dans RHS. Cinquième étape : Enfoncer le graphe de partie droite dans le graphe de contexte de LHS suivant la relation d enfoncement emb : pour chaque arc incident retiré avec un sommet v dans D et avec un sommet v dans l occurrence de LHS dans G, et pour chaque sommet v dans RHS, un nouvel arc incident est établi (même étiquette) avec l image de v et le sommet v à condition que (v, v ) appartient à emb. [54]

70 Chapitre 2 : «L ingénierie dirigée par les modèles» L application de R à un graphe G pour fournir un graphe H est appelée une dérivation directe depuis G vers H à travers R, elle est dénotée par G H. Soit S un graphe initial, le langage engendré L (P, S, T) est l ensemble des graphes dérivés à partir de S en appliquant les règles de P qui sont étiquetées par les symboles de T. La figure 2.10 illustre les différentes étapes d application d une règle de transformation. Tandis que la figure 2.11 représente le principe du système de réécriture de graphes. Règles de transformation Input Graphe source Input Système de transformation Output Graphe cible Figure 2.11 : Système de réécriture de graphe L approche de transformations de modèles a plusieurs avantages par rapport aux autres approches, nous pouvons citer: Les grammaires de graphes sont un formalisme naturel, visuel, formel et de haut niveau pour décrire les transformations. Les fondements théoriques des systèmes de la réécriture de graphes permettent d aider à vérifier certaines propriétés des transformations telles que la terminaison ou la correction. 9. Conclusion Les techniques et langages de modélisation ont pris une place importante dans la conception et le développement des systèmes complexes distribués. En effet, elles permettent de traiter l interopérabilité à un niveau d abstraction plus élevé que le niveau «code». [55]

71 Chapitre 2 : «L ingénierie dirigée par les modèles» Dans ce chapitre, nous nous sommes intéressés à l ingénierie dirigée par les modèles et ses différents principes. Nous avons survolé également les techniques de transformation et de traitement des modèles. Après quoi nous avons présenté la démarche MDA ainsi qu une introduction à la transformation de graphes. [56]

72 Chapitre 3 Cadre formel : Réseaux de Petri et Logique de réécriture

73 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» 1. Introduction Les méthodes formelles font référence à un ensemble de techniques de conception reposant sur l utilisation des modèles mathématiques pour construire des systèmes logiciels et matériels. Elles fournissent un cadre très rigoureux pour spécifier, développer et vérifier des systèmes d'une façon systématique, afin de démontrer leur validité par rapport à une certaine spécification [102]. L utilisation des méthodes formelles nécessite l adoption d un formalisme adéquat qui permet de fournir une spécification du système que l on souhaite développer à un niveau de détail désiré. Par conséquent, plusieurs formalismes ont été proposés dont nous pouvons citer : les réseaux de Petri, les automates, etc. Dans notre travail, nous nous sommes intéressés à deux formalismes à savoir les réseaux de Petri et la logique de réécriture. Ces derniers offrent un cadre approprié pour la spécification et la validation des services web. Ce chapitre est constitué de deux parties. La première est consacrée à la présentation des réseaux de Petri, un intérêt particulier sera porté sur le formalisme «G-Nets». Dans la deuxième partie, nous présenterons la logique de réécriture ainsi que son langage «Maude». 2. Les réseaux de Petri Les réseaux de Petri ont été introduits par Carl Adam Petri en 1962 dans sa thèse de doctorat [61] à l'université de Bonn, Allemagne. Ce travail a ouvert un champ d étude et a été exploité par Anatol W. Holt, F. Commoner, M. Hack et leurs collègues dans un groupe de recherche du Massachussetts Institute of Technology (MIT), dans les années 70 et c est en 1975 que la première conférence sur les réseaux de Petri et les méthodes relationnelles a été organisée au MIT. Un réseau de Petri est un outil graphique pour la description formelle des systèmes dont la dynamique est caractérisée par la concurrence, la synchronisation, l exclusion mutuelle et le conflit des choix multiples. Ces attributs sont propres aux environnements distribués. La facilité d adaptation des réseaux de Petri élargit leur champ de pratique jusqu aux protocoles de communication, architectures des ordinateurs, etc. Leur aspect mathématique leur permet l analyse des propriétés comportementales et structurelles essentielles à la validation du système. [57]

74 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» 2.1 Définition informelle Un réseau de Petri est un graphe biparti orienté ayant deux types de nœuds : des places représentées par des cercles, et des transitions représentées par des rectangles. Les arcs du graphe ne peuvent relier que des places vers des transitions, ou des transitions vers des places. Un réseau de Petri permet de décrire le comportement d un système dynamique à événements discrets. Les places décrivent les états possibles du système et les transitions permettent de modéliser les événements ou les actions qui font basculer le système d un état à un autre. Chaque place contient un nombre entier positif ou nul de jetons. Ces derniers sont utilisés pour décrire la dynamique du système. L état de ce dernier est donné par son marquage qui est défini par la distribution des jetons sur les différentes places du réseau de Petri. Un marquage M définit l'état du système décrit par le réseau à un instant donné. C est un vecteur colonne de dimension égale au nombre de places dans le réseau. Le i éme élément du vecteur correspond au nombre de jetons contenus dans la place P i. L ensemble de changements d états possibles du système est conclu à partir de l ensemble des transitions franchissables. Une transition est franchissable lorsque toutes ses places d'entrée contiennent au moins un jeton. Le franchissement consiste à retirer les jetons de chacune des places d'entrée et à ajouter d autres jetons à chacune des places de sortie d une transition. Pour plus d illustration, la figure ci-dessous représente un exemple de réseau de Petri marqué. P 2 T 2 P 4 P 1 T 1 T 4 P 6 P 3 T 3 P 5 Figure 3.1 : Exemple d un réseau de Petri marqué [58]

75 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» 2.2 Définition formelle Un réseau de Petri est défini par un 5-tuple R = {P, T, W, F, M 0 } où : P : est un ensemble fini de places différent de l ensemble vide. T : est l ensemble de transitions. W : est l ensemble des arcs orientés, W (P T) (T P). F : W N + est une fonction qui associe à chaque élément de W un entier positif qui indique combien de jetons sont consommés depuis une place vers une transition, ou sinon, combien de jetons sont produits par une transition et arrivent pour chaque place. M 0 : P N est le marquage initial du réseau de Petri. Nous introduisons les quatre notations suivantes : Soit p P: p = {t T (t, p) W}. c.à.d. p est l ensemble des transitions d entrée de la place p. Soit p P: p = {t T (p, t) W}. c.à.d. p est l ensemble des transitions de sortie de la place p. Soit t T: t = {p P (p, t) W}. c.à.d. t est l ensemble des places d entrée de la transition t. Soit t T: t = {p P (t, p) W}. c.à.d. t est l ensemble des places de sortie de la transition t. Nous constatons donc que «p» et «p» sont des sous-ensembles de T. Tandis que «t» et «t» sont des sous-ensembles de P. Dans le réseau de Petri de la figure 3.1 nous avons, par exemple : P 1 = P 5 = {t 3 } P 6 = t 1 = {P 2, P 3 } t 4 = {P 4, P 5 } Une transition t (resp. place p) d un réseau de Petri est une transition source (resp. place source) si et seulement si t = (resp. p = ). c.à.d. une transition source (resp. place source) n a pas de place d entrée (resp. transition d entrée). Une transition t (resp. place p) d un réseau de Petri est une transition puits (resp. place puits) si et seulement si t = (resp. p = ). c.à.d. une transition puits (resp. place puits) n a pas de place de sortie (resp. transition de sortie). [59]

76 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» 2.3 Fonctionnement d un réseau de Petri ordinaire Le comportement d'un réseau de Petri est déterminé par sa structure statique et par son état. L évolution du réseau au cours du temps est animée par le franchissement des transitions qui correspond à l exécution de certaines actions Validation d une transition Une transition «t» est franchissable (valide ou sensibilisée) dans un réseau de Petri marqué R (P, T, W, F, M) si et seulement si : p i t : M (p i ) F (p i, t) Ceci signifie que pour toutes les places p i, en entrée de t, le nombre de jetons dans p i (M (p i )) est supérieur ou égal à la valeur de l arc allant de p i à t (F(p i,t)). La notation «M [t>» dénote que la transition t est franchissable dans le marquage M. Remarque: Une transition source est toujours sensibilisée. Comme elle n a aucune place en entrée, le sous-ensemble t est l ensemble vide et la condition de franchissabilité est vérifiée pour tout marquage Franchissement d une transition Dans un réseau de Petri ordinaire, toute transition franchissable t peut être tirée et son tir (exécution) consiste à retirer F (p i, t) jetons dans chacune des places d entrée p i de t et à ajouter F (t, p j ) marques dans chacune des places de sortie p j de t. Plus formellement, le franchissement d une transition «t» à partir d un marquage «M» conduit à un marquage «M» définit par : M (p)= M(p) - F (p, t) + F (t, p) Si : p ( t t ). p P M (p)= M(p) - F (p, t) Si : p t p t. M (p)= M(p) + F (t, p) Si : p t p t. M (p)= M(p) Si : p ( t t ). La notation «M (t>m» dénote le fait que le franchissement de «t» à partir du marquage «M» conduit au marquage «M». Donc, «M» est un marquage successeur de «M». [60]

77 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Pour plus d illustration, la figure ci-dessous représente un exemple de franchissement d une transition «t». M (p 1, p 2, p 3, p 4 ) = [4, 1, 2,0] p 1 p 2 M (p 1, p 2, p 3, p 4 ) = [3, 1, 3,1] p 1 p 2 t t p 3 p 4 p 3 p 4 Figure 3.2 : Franchissement de transition Séquences de franchissement Une séquence de franchissement «S» est une suite de transitions T i, T j,,t n qui peuvent être franchies successivement à partir d'un marquage donné. Une seule transition peut être franchie à la fois. La notation «M i [S > M n» exprime que le franchissement de la séquence S à partir du marquage «M i» conduit au marquage «M n» Graphe des marquages accessibles L ensemble des marquages accessibles A (R, M o ) est défini par : M o A (R, M o ). Si M A (R, M o ) et M [t>m alors M A (R, M o ). Cette définition signifie que le marquage initial M o est un marquage accessible et tout marquage successeur d un marquage accessible est un marquage accessible. Le graphe des marquages accessibles G (R, M o ) est défini comme le graphe dont les nœuds sont les marquages accessibles de A (R, M o ) et dont les arcs sont les noms des transitions impliquées dans les tirs menant d un marquage à un autre. [61]

78 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Prenant le réseau de Petri de la figure 3.1, l ensemble des marquages accessibles est {M 0, M 1, M 2, M 3, M 4, M 5 }. Le graphe de marquages est représenté par la figure ci-dessous : M 0 = (1, 0, 0, 0, 0, 0) T 1 M 1 = (0, 1, 1, 0, 0, 0) T 2 T 3 M 2 = (0, 0, 1, 1, 0, 0) M 3 = (0, 1, 0, 0, 1, 0) T 3 T 2 M 4 = (0, 0, 0, 1, 1, 0) T 4 M 5 = (0, 0, 0, 0, 0, 1) Figure 3.3 : Graphe de marquages 2.4 Modélisation des systèmes complexes en utilisant les réseaux de Petri L avantage principal des réseaux de Petri réside dans leur capacité à modéliser un grand nombre de comportements dans les systèmes complexes. Parmi ces comportements, nous pouvons citer : le parallélisme, la synchronisation, le partage de ressources, la mémorisation, la lecture d informations, etc Le parallélisme Le parallélisme est défini comme l évolution simultanée de plusieurs processus dans un même système. Dans un réseau de Petri, le parallélisme est modélisé par une transition ayant plusieurs places de sortie. La figure 3.4 représente un exemple de parallélisme. P 1 t P 2 P 3 Processus 1 Processus 2 Figure 3.4 : Exemple de parallélisme [62]

79 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Le franchissement de la transition «t» permet de mettre un jeton dans la place P 2, et un jeton dans la place P 3, ce qui marque le déclenchement du processus 1 et du processus 2 en parallèle La synchronisation Il existe deux types de synchronisation : la synchronisation mutuelle (par rendez-vous) et la synchronisation par signal (sémaphores) La synchronisation mutuelle Elle permet de synchroniser les opérations d un ensemble de processus. La figure cidessous montre un exemple de deux processus. Pour franchir la transition t m, il faut que la place P e qui correspond au processus1 et la place P j qui correspond au processus 2 contiennent chacune au moins un jeton. Autrement, si par exemple la place P e ne contient pas de jetons, le processus 2 reste bloqué sur la place P j ; il attend que le processus 1 réussisse à créer un jeton dans la place P e au cours de son évolution. P e P j Processus 1 Processus 2 t m P f P k Figure 3.5 : Synchronisation mutuelle La synchronisation par signal Dans ce type de synchronisation, Les opérations du processus 2 se poursuivent à condition que le processus 1 ait atteint un certain niveau dans son évolution. Ceci n est pas le cas du processus 1 qui ne dépend pas de l avancement des opérations du processus 2. Un exemple est illustré dans la figure 3.6. [63]

80 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Attente Processus 1 Processus 2 Signal Figure 3.6 : Synchronisation par signal Si la place «Signal» est marquée et la place «Attente» ne l est pas, cela signifie que le processus 1 a envoyé le signal mais le processus 2 ne l a pas encore reçu. Si, à l inverse, la place «Signal» n est pas marquée et la place «Attente» est marquée, cela signifie que le processus 2 est en attente du signal Le partage de ressources Il s agit de modéliser le cas de plusieurs processus se partageant une même ressource dans un même système, en utilisant l exclusion mutuelle. P c P h t c Processus 1 Processus 2 t h P d P i t k P r t m Figure 3.7 : Exemple d un partage de ressource Dans la figure ci-dessus, le jeton dans la place P r représente une ressource commune entre le processus 1 et le processus 2. Après le franchissement de la transition t c lors de l évolution [64]

81 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» du processus 1, le jeton de la place P r est alors consommé. La ressource que constitue ce jeton n est alors plus disponible pour l évolution du processus 2. Lors du franchissement de la transition t k, un jeton est placé dans la place P r, et la ressource est de nouveau disponible La mémorisation Une place sans sortie peut être utilisée dans tous les modèles pour compter le nombre de tirs d une transition. Dans la figure 3.8, les places «Attente» et «Compteur» peuvent indiquer combien d instances d un processus sont en attente. Attente Compteur Figure 3.8 : Exemple de mémorisation 2.5 Extensions des réseaux de Petri Les réseaux de Petri ordinaires permettent la modélisation des systèmes concurrents de façon efficace. Ils offrent également une panoplie de méthodes d analyse qui permettent de vérifier les propriétés des systèmes modélisés. Cependant l utilisation effective des réseaux de Petri ordinaires pour la modélisation des systèmes réels conduit souvent à la manipulation de très grands modèles difficiles à comprendre. Pour pallier à ce problème, les réseaux de Petri ordinaires ont été étendus et de nouveaux types de réseaux de Petri ont été définis. Ces extensions permettent une économie d écriture et de lecture souvent nécessaire à la description de grands systèmes, elles permettent également d augmenter le niveau d expressivité. Parmi ces extensions nous pouvons citer : «les réseaux de Petri Prédicats/Transitions», «les réseaux de Petri Colorés», «les G-Nets», etc. Dans ce qui suit, nous nous intéressons aux «G-Nets» qui représentent une sorte de réseaux de Petri orientés objet. [65]

82 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Les G-Nets Les systèmes distribués sont composés d un ensemble de processus (composants) communicants qui coopèrent entre eux dans le but de résoudre un problème commun. La conception d'un système logiciel distribué, comme le cas de bien d'autres, présente de nombreuses difficultés. Par conséquent, les formalismes de spécification et de conception de ces systèmes doivent supporter la coordination et la communication des activités à différents niveaux d'abstraction. L un des aspects les plus importants qui doit être considéré lors de la spécification et de la conception d'un système distribué complexe est sa concurrence inhérente. En outre, il faut tenir compte des propriétés structurelles du système, ainsi que des comportements de composants et des messages de communication échangés entre ces composants. Le problème de la gestion de systèmes distribués est principalement une question de modularité. Par conséquent, il serait souhaitable de découper les applications d un système en plusieurs parties relativement indépendantes appelées modules, où chaque module masque ses détails internes de traitement et communique avec les autres modules à travers des interfaces bien définies. L un des formalismes qui répond à ces exigences et qui est largement utilisé dans la spécification et la conception des systèmes distribués est le modèle «G-Nets» G-Nets et systèmes G-Net Les G-Nets, introduits par Deng et al. Dans [11], constituent un framework basé sur les réseaux de Petri. Il est utilisé pour la conception modulaire des systèmes d'information complexes et distribués. Ce framework prévoit un formalisme qui intègre la structuration orientée objet dans les réseaux de Petri. L'idée étant d une part, de bénéficier du traitement formel et de la facilité d expression des réseaux de Petri, et d autre part d acquérir les avantages de l approche orientée objet (la réutilisation, l encapsulation, etc.). Un système conçu par le biais de ce formalisme consiste en un ensemble de modules autonomes et faiblement couplés appelés «G-Nets» [11]. Un G-Net vérifie la propriété d encapsulation, c.à.d. aucun module ne peut accéder à un autre module qu à travers un mécanisme bien défini. Ceci permet d éviter les interférences d un module dans la structure interne d'un autre. [66]

83 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Structure des G-Nets Un G-Net est constitué de deux parties: une GSP (Generic Switch Place) et une structure interne (IS pour Internal Structure). La GSP est une place spéciale générique qui représente l'abstraction du module, elle sert d'interface entre le G-Net et les autres modules. La structure interne est la partie cachée du G-Net, elle représente la réalisation interne du système conçu. La notation utilisée pour spécifier la structure interne est très proche de la notation réseau de Petri. En effet, le comportement d un G-Net est décrit dans sa structure interne par les notations des réseaux de Petri augmentées par des directives permettant d indiquer la communication ainsi que la terminaison d exécution de ce G-Net. La figure ci-dessous montre les notations utilisées pour représenter les G-Nets. GSP (Non de G-Net) <Nom d attribut> = {<Type>} <Nom <Nom de la d attribut> méthode> = = {[<P {<Type>} 1, P 2, P n >] (Places initiales) (Places finales)} Place Normale (Ordinaire) Condition Action Transition Autres éléments de la structure interne Place Goal (Finale) ISP(G, mtd i ) Place ISP Figure 3.9 : Notations utilisées pour représenter un G-Net La GSP est constituée d un ensemble d attributs et de méthodes. Chaque méthode possède un nom, elle est définie par une suite de paramètres ainsi que par l ensemble de ses places initiales et finales. La notation «GSP (Non de G-Net)» permet de définir le nom (l identificateur unique) du G-Net. La structure interne du G-Net est constituée d un ensemble de places et de transitions reliées par des arcs. [67]

84 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Comme le montre la figure 3.9, les G-Nets supportent trois type de places (Places normales, places finales et places ISP s ) : Les places normales représentent des primitives. Ces dernières peuvent être des actions, des prédicats, etc. Les places ISP s (Instantiated Switching Places) sont utilisées pour représenter la communication inter-g-nets. L inscription «ISP (G', mtd i )» dans la place ISP indique l invocation de la méthode «mtd i» du G-Net «G'». Les places finales permettent de représenter la fin d exécution des méthodes. Les transitions dans un G-Net peuvent exécuter une action (une suite d affectations de valeurs à des variables), comme elles peuvent avoir des conditions de garde. Les notations graphiques proposées par les G-Nets fournissent un moyen intuitif pour spécifier les systèmes en termes de modules qui favorisent l'abstraction, l'encapsulation et le couplage faible entre ces modules. D autre part, le comportement de chaque module (G-Net) est décrit dans les bases des réseaux de Petri Structure de jetons Le framework G-Net permet l exécution de plusieurs invocations d'un G-Net simultanément. Cette caractéristique est due à la structure de jeton unique utilisée dans le cadre des G-Nets. Un jeton «tkn» est défini comme un triplet tkn = (seq, sc, msg) où : tkn.seq (Séquence de propagation): c est une séquence de (Nid, isp, Pid) telle que: «Nid» : est l identificateur du G-Net. «isp» : est le nom d un ISP du G-Net. «Pid» : est l identificateur du processus. La séquence de propagation d'un jeton est seulement changée dans une place ISP et dans une GSP. Quand un G-Net «G» invoque un autre G-Net «G» à partir d une place ISP «isp i», cette dernière, lors de la réception d un jeton, ajoute le triplet (G, isp i, Pid G ) à la séquence de propagation du jeton reçu avant de l envoyer au G-Net «G». Ce triplet indique que lorsque l'exécution de «G» est terminée le jeton résultant doit être retourné à la place, du G-Net «G», identifiée par «isp i». L'identificateur de processus «Pid G» est nécessaire pour distinguer à quelle instance [68]

85 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» d exécution de G-Net «G» le jeton retourné appartient. Lorsque le jeton est reçu par la place GSP du G-Net «G», cette place ajoute le triplet (0, 0, Pid G ) à la fin de la séquence de propagation pour indiquer que l'agent chargé de l'exécution de l'invocation est identifié par «Pid G». La structure de jeton dans le framework «G- Net» garantit non seulement que tous les jetons qui appartiennent à une instance d'exécution du G-Net ont le même identificateur de processus, mais contient également l'historique complet de la propagation des jetons, qui régit les interactions entre les processus d'exécution d'une spécification G-Net. tkn.sc (La couleur du statut du jeton) : elle peut avoir deux valeurs possibles, soit «Before» ou «After». Un jeton est considéré comme disponible si son sc = «After», sinon, il est dit indisponible. Lorsqu'un nouveau jeton est reçu par une place, cette dernière affecte la valeur «Before» à la couleur du statut de ce jeton. Après l exécution de l action associée à la place, elle réaffecte la valeur «After» à la couleur du statut. Ceci indique que le jeton est prêt à être utilisé par des transitions subséquentes. Le champ «tkn.msg» est une liste de valeurs spécifiques à l'application. Il contient les différentes données manipulées par le G-Net Franchissement d une transition Dans le framework «G-Net», le mécanisme de franchissement des transitions est défini par l ensemble des règles suivantes : Une transition «t» est dite valide (active) si et seulement si : Chaque place p t contient au moins un jeton dont le contenu satisfaisant la condition de garde de la transition «t». Tous Ces jetons appartiennent à la même instance d exécution du G-Net. Tous les jetons indiqués précédemment ont leurs sc = «After». Le nombre de jetons dans les places p t est inférieur à leurs capacités (dans le cas où les places de G-Net possèdent une capacité limité). Après le franchissement de la transition «t» : Tous les jetons déclenchant la transition sont supprimés de ses places p t. Un jeton dont la séquence de propagation est la même que celui de jetons retirés des places p t est déposé dans chaque place p t. [69]

86 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Invocation d un G-Net L'invocation d'une méthode mtd G.MS du G-Net «G» est effectuée de la manière suivante : 1) Déterminer le marquage initial de «G» en se basant sur la définition de la méthode mtd. 2) Exécuter les différentes transitions valides (s'il y en a). 3) Exécuter les différentes primitives (s'il y en a). 4) Répéter (1) et (2) jusqu'à ce qu une place goal soit atteinte. 5) Envoyer le résultat de l'exécution (s il est défini par la méthode mtd) à l'invocateur. L'exécution d'une spécification G-Net est réalisée par un ensemble de processus concurrents appelés «Agents». Un G-Net peut être associé à l'un des deux modes d'exécution à savoir le mode «Instanciation» ou le mode «Serveur». Dans le mode «Instanciation», la fonction d'un agent se résume seulement en l exécution d une instance d invocation G-Net en se basant sur une méthode déterminée. Un nouvel agent est créé pour chaque instanciation du G-Net, la fonction de cet agent se termine lorsque l'instance d exécution du G-Net s achève. Dans le mode «Serveur», un seul agent est associé à un G-Net spécifiant un serveur. L'agent est appelé «agent serveur», il gère toutes les requêtes de clients. Après avoir présenté les concepts de base des réseaux de Petri ainsi que le formalisme G- Net, nous présentons dans ce qui suit un autre formalisme permettant la spécification et la vérification formelle des systèmes concurrents, il s agit de la logique de réécriture. 3. La logique de réécriture La logique de réécriture a été introduite initialement par José Meseguer dans [104] comme une conséquence de son travail sur les logiques générales pour décrire les systèmes informatiques, plus particulièrement les systèmes concurrentiels. La théorie et les applications de la logique de réécriture ont été vigoureusement développées par des chercheurs du monde entier au cours des dernières années. À ce jour, plus de six cents documents relatifs à cette logique ont été publiés. [70]

87 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» La logique de réécriture est dotée d une sémantique saine et complète. Elle permet de raisonner d'une manière correcte sur les systèmes concurrentiels non-déterministes ayant des états et évoluant en termes de transitions. Dans cette logique l aspect statique des systèmes est représenté par une logique sous-jacente à savoir la logique équationnelle. Tandis que l aspect dynamique est représenté par des théories de réécritures décrivant les transitions possibles entre les états du système. Pour plus d illustration, nous présentons dans ce qui suit les différentes notions formelles nécessaires à la compréhension de la logique de réécriture. 3.1 Théorie équationnelle En plus d'être aisément exécutable, la logique des équations est particulièrement intéressante comme cadre mathématique pour les systèmes impératifs séquentiels [104]. Dans cette section nous présentons les différents concepts relatifs à cette logique Signature Une signature de la logique équationnelle décrit la syntaxe de la théorie. C est une paire = où : est un ensemble de noms de sortes : S 1, S 2,, S q. est un ensemble non vide d opérations de la forme : S 1 S 2 S n-1 S n. (S 1, S 2, S n-1, S n ) est appelé le profil de l opération. S 1, S 2, S n-1 est le domaine de. S n est le co-domaine de. N-1 est l arité de. Les constantes sont des opérations d arité nulle. L exemple ci-dessous illustre bien la notion de signature, il représente une simple signature des nombres entiers naturels. Sortes: Nat S Opérations: Zéro : Nat Successeur : Nat Nat F _+_ : Nat Nat Nat [71]

88 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Algèbre Soit une signature =, une -algèbre A de est donnée par : Un ensemble pour toute sorte (cet ensemble est appelé le «support» de ). Pour chaque opération dont le profil est (S 1, S 2, S n-1, S n ), une fonction, appelée interprétation de f dans A. Il est à noter que «Alg ( )» représente la classe de toutes les -algèbres (toutes les interprétations possibles de ). L interprétation d une opération constante est une fonction constante qui détermine un élément de A Les termes Soit «=» une signature, «V» un ensemble infini dénombrable de variables, et «C» est l ensemble de valeurs constantes relatives à la signature : Tout symbole de constante (c C) est un terme. Toute variable (v V) est un terme. Si est une opération d arité N et si t 1,..., t n sont des termes, alors (t 1,..., t n ) est un terme. Un terme qui ne contient pas de variable est appelé «terme clos». À titre d exemple la phrase «Successeur (Zéro)» correspond à un terme défini par la signature des nombres entiers naturels présentée précédemment. La notation (V) est utilisée pour désigner l ensemble des termes T formés à partir de et l ensemble des variables V équation Soit «=» une signature et «V» un ensemble de variable, une -équation est une paire (t, t ) où t et t (V). A : Une -équation (t, t ) est notée t = t. Nous prenons toujours la signature des nombres entiers naturels, «N + Zéro = N» est une -équation où N est une variable. [72]

89 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Spécification algébrique Une spécification algébrique est une paire Spec = (, E) où : : est une signature. «E» : est un ensemble de -équations. L exemple ci-dessous représente une spécification algébrique des nombres entiers naturels. Sortes: Nat S Opérations: Zéro : Nat Successeur : Nat Nat F _+_ : Nat Nat Nat Spec Variables : N, M: Nat Equations : Zéro + N = N Successeur (M) + N = Successeur (M + N) -équations 3.2 Théorie de réécriture Dans la logique de réécriture, chaque système concurrent est représenté par une théorie de réécriture. Etant donné une théorie équationnelle (, E), une théorie de réécriture est un quadruplet = (, E, L, R) tel que : : est un ensemble d opérations (symboles de fonctions) et de sortes. «E» : est un ensemble de -équations. «L» : est un ensemble d étiquettes. «R» : est un ensemble de paires R T, E (V)) 2 tel que le premier composant est une étiquette, et le second est une paire de classes d équivalences de termes modulo les équations E avec V= { v 1, v n, } un ensemble infini et dénombrable de variables. Les éléments de «R» s appellent les règles de réécriture. Ils décrivent les transitions élémentaires et locales dans un système concurrent. Chaque règle de réécriture correspond à une action pouvant se produire en concurrence avec d'autres actions. Pour décrire une règle de réécriture nous utilisons la notation suivante r : [t] [t ]. [73]

90 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» En outre, pour indiquer que {v 1, v n } est l ensemble de variables apparaissant dans t ou bien dans t nous écrivons r : [t(v 1, v n )] [t (v 1, v n )], ou par une notation abrégée r : [t Règles de déduction Soit une théorie de réécriture, nous disons qu'une séquence r : [t] [t ] est prouvable dans ou r : [t] [t ] est -réécriture concurrente et nous écrivons r : [t] [t ] si et seulement si [t] [t ] est obtenue par une application finie des règles de déduction suivantes : Réflexivité : pour chaque [t] T, E (V) Congruence : Pour chaque symbole de fonction n, n N Remplacement : Pour chaque règle de réécriture r : [t(v 1, v n )] [t (v 1, v n )] dans R Tel que représente la substitution des par, 1 i n. Transitivité : Modèle d une théorie de réécriture Le modèle d une théorie de réécriture = (, E, L, R) est une catégorie (V) dont les objets sont des classes d'équivalence des termes [t] T, E (V), et les morphismes sont des classes d'équivalence des termes-preuves (proof-terms) représentant des preuves dans la déduction de réécriture. Voir [105, 106] pour une introduction plus détaillée à l aspect sémantique de la logique de réécriture. [74]

91 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» La logique de réécriture offre un cadre sémantique dans lequel un grand nombre de langages et de modèles de concurrence peuvent être représentés. Parmi ces modèles nous pouvons citer : les réseaux de Petri, les automates, la machine chimique abstraite, etc. La logique de réécriture bénéficie aussi de la présence de nombreux langages et environnements opérationnels, le plus connus étant le langage Maude. 3.3 Le langage Maude Maude [13, 14] est un langage formel de spécification et de programmation déclarative basé sur la logique de réécriture. Il a été développé par le centre de recherche américain «SRI international 1» en collaboration avec le département d'informatique de l université de l'illinois à Urbana-Champaign 2. Ce langage constitue la seule implémentation de la logique de réécriture qui emploie systématiquement et d une manière efficace le mécanisme de réflexivité. Une spécification Maude définit une théorie de la logique de réécriture. Les types de données sont définis algébriquement par des équations, et le comportement dynamique du système est défini par des règles de réécritures. En outre, Maude supporte également la programmation orientée objet avec l'inclusion de l'héritage multiple et la communication asynchrone [107]. Il est important de noter que Maude permet de programmer à deux niveaux différents: «Core Maude» et «Full Maude». L'unité de base pour le développement Maude est le module. Donc pour spécifier un système en utilisant Maude, il faut écrire un ensemble de modules permettant de décrire ce système. Avant de présenter les niveaux de programmation Maude ainsi que les différents types de modules offerts par ce langage, nous présentons d abord dans ce qui suit quelques caractéristiques ainsi que la syntaxe du langage Maude Caractéristiques du langage Maude Le langage Maude présente un ensemble de caractéristiques intéressantes dont nous pouvons citer : [75]

92 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» La simplicité : Maude est un langage déclaratif qui offre des notions de programmation simples et faciles à comprendre. En effet, les expressions de base de ce langage sont soit des équations soit des règles de réécriture. L expressivité : Le langage Maude permet d'exprimer naturellement une vaste gamme d'applications, en commençant par les programmes déterministes arrivant aux programmes hautement concurrentiels. En outre, la sémantique rigoureuse de Maude permet non seulement d exprimer des applications, mais aussi des formalismes entiers (d'autres langages, d'autres logiques). De ce fait, Maude est vu comme étant un «métalangage» avec lequel il est facile de développer un langage spécifique. La puissance et la performance : En plus d être un langage de spécification formelle, Maude est un véritable langage de programmation compétitif. Il permet l exécution de millions de règles de réécriture par seconde. En plus de ces caractéristiques, Maude est considéré comme un langage «Multiparadigme». En effet, il permet la combinaison de la programmation déclarative et orientée objet Syntaxe du langage Maude Dans cette section, nous présentons les notions syntaxiques les plus intéressantes du langage Maude (les sortes, les sous sortes, les opérations, etc.) Les sortes Les sortes (les types de données) sont les premières choses à définir dans une spécification. Pour déclarer un nouveau type en Maude, il faut utiliser le mot clé «sort» suivi par le nom de la sorte comme suit : sort (nom de la Sorte). Dans le cas où nous avons plusieurs sortes à déclarer, nous pouvons utiliser le mot clé «sorts» de la manière suivante : sorts (nom de la première Sorte) (nom de la deuxième Sorte) (nom de la dernière Sorte). [76]

93 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» L exemple ci-dessous montre la déclaration de deux sortes Nat (les nombres entiers naturels) et NzNat (nombres entiers naturels non nuls): Sort Nat. Sort NzNat. Ou Sorts Nat NzNat Les sous-sortes La relation de sous-sorte est équivalente à la relation de sous-ensemble. C.à.d. Soit S 1 une sous-sorte de S 2 : tous les éléments de S 1 appartiennent à S 2, alors que l'inverse n'est pas forcément vrai. Les sous-sortes sont déclarées en utilisant le mot clé «subsort» comme suit : subsort (nom de la Sous sorte) < (nom de la sorte). La déclaration ci-dessous signifie que «NzNat» est une sous-sorte de «Nat». subsort NzNat < Nat Les opérations Pour déclarer une opération, il faut utiliser le mot clé «op» de la façon suivante : op (nom de l opération) : (Sorte 1 ) (Sorte 2 ) (Sorte K ) -> (Sorte) (Sorte 1, Sorte 2,, Sorte K ) est la liste des sortes formant les arguments (le domaine) de l opération. Tandis que (Sorte) représente la sorte du résultat (le co-domaine). Maude offre la possibilité de déclarer plusieurs opérations grâce au mot clé «ops», à condition que toutes ces opérations possèdent le même domaine et co-domaine. Dans l exemple suivant nous présentons quelques déclarations d opérations en Maude. op successeur_ : Nat -> Nat. ops _+ *_ : Nat Nat -> Nat. [77]

94 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» La surcharge des opérations Dans Maude, les opérateurs peuvent être surchargés. C.à.d. nous pouvons avoir plusieurs déclarations pour le même opérateur avec des domaines et des co-domaines différents. Par exemple l opération _+_ peut être surchargée, en donnant deux déclarations à ce même opérateur pour deux sortes différentes (les nombres entiers naturels et les chaines de caractères): op _+_ : Nat Nat -> Nat. ops _+_ : String String -> String Les variables Une variable représente une valeur indéfinie d une sorte. Elle est déclarée dans Maude avec le mot clé «var» (ou «vars» pour plusieurs variables de la même sorte). Un exemple de déclarations de variables (S, X, Y et Z) est le suivant: var S : String. var X : Nat. vars Y Z : Nat Les équations Nous rappelons qu un terme est une constante, une variable ou bien le résultat de l application d'une opération sur un ensemble de termes. Maude supporte deux types d équations : Les équations inconditionnelles : une équation inconditionnelle est déclarée à l aide de mot clé «eq» de la manière suivante : eq (Terme 1 ) = (Terme 2 ). Les équations conditionnelles : pour déclarer une équation conditionnelle, il faut utiliser le mot clé «ceq». La forme d une équation conditionnelle est la suivante : ceq (Terme 1 ) = (Terme 2 ) if (Condition 1 ) / \ (Condition 2 ) / \ / \ (Condition n ). L opérateur «/ \» (condition-concatenation operator) permet de relier les différentes conditions d une équation conditionnelle. [78]

95 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Les règles de réécriture À l instar des équations, Maude offre deux types de règles de réécriture : Les règles de réécriture inconditionnelles : une règle de réécriture inconditionnelle a la syntaxe suivante: rl [étiquette] : (Terme 1 ) => (Terme 2 ). Les règles de réécriture conditionnelles : la forme d une règle de réécriture conditionnelle est la suivante : crl [étiquette] : (Terme 1 ) => (Terme 2 ) if (Condition 1 ) / \ / \ (Condition n ) Importation de modules Comme dans la plupart des langages de programmation, Maude offre la possibilité d importer d autres modules. Ceci permet aux développeurs de bénéficier de toutes les déclarations et les définitions des modules importés. Ce mécanisme permet de minimiser la redondance dans les spécifications. En plus, il permet d offrir une meilleure modularité. Maude supporte trois modes d importation : «Protecting» : dans ce mode, le développeur ne peut pas modifier les déclarations du module importé. C.à.d. toutes les opérations définies et les sortes sont employées strictement comme elles sont dans le module importé. «Including» : dans ce mode, le développeur peut changer librement le sens des éléments déclarés dans le module importé. «Extending» : dans ce mode, le développeur peut ajouter de nouveaux termes à une sorte mais il ne peut pas modifier la signification des opérations. La syntaxe d utilisation de ces trois modes est la suivante : protecting (nom du module). including (nom du module). extending (nom du module). [79]

96 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Les modules L unité de base pour le développement Maude est le module. Il en existe trois types: Les modules fonctionnels Ce sont des théories équationnelles. Ces modules définissent les types de données et les opérations qui sont utilisés par les équations. Les modules fonctionnels sont déclarés avec la syntaxe suivante : fmod (nom du module) is CORPS endfm. Pour plus d illustration, nous reprenons le réseau de Petri de la figure 3.1, le module fonctionnel ci-dessous définit la structure syntaxique du réseau de Petri. fmod PN-SIGNATURE is sorts Place Marking. ops P 1 P 2 P 3 P 4 P 5 P 6 : -> Place. op nill : -> Place. op _ : Place -> Marking. op _._ : Marking Marking -> Marking. vars X Y Z : Marking. eq X. nill = X. eq X. Y = Y. X. eq X. (Y. Z) = (X. Y). Z. endfm Les modules systèmes Ce sont des théories de réécriture. Ils permettent de spécifier le comportement d'un système concurrent. Les modules systèmes ajoutent à la définition des modules fonctionnels les règles de réécriture. L'introduction de ces règles permet d'exprimer la concurrence dans les systèmes. [80]

97 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Les modules système en Maude sont déclarés avec la syntaxe suivante : mod (nom du module) is CORPS endm. Pour décrire le comportement du réseau de Petri de la figure 3.1, nous reprenons le module fonctionnel «PN-SIGNATURE» auquel nous ajoutons des règles de réécriture associées aux transitions dans le module système suivant : mod PETRI-NET is extending PN-SIGNATURE. rl [T 1 ] : P 1 => P 2 P 3. rl [T 2 ] : P 2 => P 4. rl [T 3 ] : P 3 => P 5. rl [T 4 ] : P 4 P 5 => P 6. endm Les modules orientés objet Bien que les modules systèmes sont suffisants pour la spécification des systèmes orientés objet, ces derniers peuvent être définis par le biais des modules orientés objet. Ces modules sont transformés en des modules systèmes pour des buts d'exécution. Les modules orientés objet sont déclarés avec la syntaxe suivante : omod (nom du module) is CORPS endom Les niveaux de programmation Maude Comme nous l avons précédemment mentionné, Maude permet de programmer à deux niveaux différents «Core Maude» et «Full Maude». Nous pouvons différencier les deux niveaux par ce qui suit: [81]

98 Chapitre 3 : «Cadre formel : Réseaux de Petri et Logique de réécriture» Core Maude «Core Maude» est le niveau de base de Maude. C est un interpréteur programmé directement en C++. Il implémente toutes les fonctionnalités de base de Maude, intégrant les modules fonctionnels et les modules systèmes. Core Maude intègre d autres modules tels que : les modules prédéfinis des types de données et le module Model-Checker ; la réflexivité et la fonction meta-langage sont aussi prises en compte Full Maude «Full Maude» est une extension du «Core Maude» écrite en langage Maude. Tous les concepts présents dans«core Maude» sont aussi présents dans «Full Maude» mais avec quelques restrictions syntaxiques à respecter. En plus des modules fonctionnels et systèmes, «Full Maude» supporte les modules orientés objet. Il dote Maude d un environnement puissant et extensible dans lequel les modules peuvent être combinés pour donner d autres modules complexes. 4. Conclusion Dans ce chapitre nous nous sommes intéressés à deux des formalismes les plus utilisés dans le domaine de la spécification formelle des systèmes complexes. Il s agit des réseaux de Petri et de la logique de réécriture. Dans un premier temps, nous avons présenté les concepts de base des réseaux de Petri, nous nous sommes intéressés tout particulièrement au formalisme des «G-Nets». Dans un deuxième temps, nous avons présenté la logique de réécriture à travers les éléments de base de ses deux constituants à savoir les théories équationnelles et les théories de réécriture. Enfin nous avons présenté les différents concepts de base qui entourent le langage «Maude». [82]

99 Chapitre 4 Une approche intégrée G-Nets/Maude pour la modélisation, la composition et la vérification des services web

100 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» 1. Introduction Comme nous l'avons déjà présenté dans le premier chapitre, les technologies basées sur WSDL, UDDI et SOAP offrent des solutions pour la description, la publication, la découverte et l'interopérabilité des services web, mais ne permettent pas d effectuer leur composition qui reste une tâche complexe. Pour résoudre ce problème, plusieurs langages de composition des services web ont été proposés tels que : BPEL, WSCI, etc. Il s agit malheureusement de langages textuels exécutables conçus pour satisfaire à la phase d implémentation d un service web composé et qui négligent de fait l étape de spécification qui est importante, car elle facilite la compréhension globale du système ainsi que la tâche de développement. De plus, l analyse formelle des langages proposés n est pas possible à cause de leur manque de formalisme. Un service web qui contient des erreurs peut amener à perdre des clients. Ce problème est plus grand quand il concerne les services web des domaines critiques où les enjeux humains et économiques sont importants. Donc il est nécessaire de disposer d une méthode qui permet d analyser et de garantir que les services web vérifient certaines propriétés comportementales (telles que les propriétés de sureté et de vivacité) avant leurs mises en œuvre, dans le but de fournir et de créer des services web corrects. Dans ce chapitre, nous allons proposer une approche dirigée par les modèles qui permet la spécification, la composition et la vérification formelle des services web. Nous commencerons d abord par la phase de la modélisation tout en présentant les définitions formelles des «services web» et des «G-Net services». Après quoi, nous définirons une algèbre qui résout avec succès la composition complexe des services web. Pour terminer, nous aborderons le sujet de la vérification formelle des services web. Comme le montre la figure 4.1 notre approche peut être divisée en trois phases principales : La phase de modélisation : Elle permet de spécifier des services web en termes de «G-Net services». La phase de composition : Elle permet de combiner et de composer les services web modélisés par des «G-Net services» en se basant sur une algèbre de composition que nous avons proposé. [83]

101 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» La phase de vérification : Elle permet d analyser le comportement des services web (simples ou composés) tout en vérifiant des propriétés telles que la sûreté, l atteignabilité ou la vivacité, afin d assurer la fiabilité et la qualité des services web développés. Non Modélisation Vérification Modélisation correcte Oui Composition Non Composition correcte Oui Oui Figure 4.1 : Schéma illustratif des différentes phases de notre approche 2. Les services web en tant que G-Net services À l instar d un système G-Net, les services web sont assimilés à un système distribué composé d'un ensemble de modules faiblement couplés qui communiquent entre eux via un échange de messages. Afin de modéliser les services web, nous avons proposé la notion des «G-Net services». Ces derniers étendent les G-Nets classiques par une fonction d étiquetage «L» qui permet d associer un nom d opération à chaque place du G-Net. L idée de modélisation est simple, elle consiste en : La modélisation de chaque service web par un «G-Net service». La représentation des variables du service web par des attributs dans le G-Net service. La modélisation de chaque fonction du service web par une méthode dans le G-Net. L association d un fragment de réseau de Petri dans l IS à chaque méthode. [84]

102 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» La modélisation des interactions du service par des places «ISP». L état du service web est représenté donc par la position des jetons dans le G-Net service. Dans ce qui suit, nous donnons quelques définitions formelles sur «les G-Net Services» et «les services Web». 2.1 Les G-Net Services Un G-Net service est un G-Net ( ) [108] où: ( ) est une place spéciale représentant l abstraction du service tels que : AS est l ensemble des attributs de la forme «nom-attribut»= {«type»} où «nom-attribut» est le nom de l attribut et «type» est le type de l attribut. est un ensemble de méthodes exécutables de la forme : «NomMtd» «description»= {[P 1 : description,.., P n : description] («InitPl») («GoalPls»)} dans la quelle «NomMtd» et «description» désignent respectivement le nom et la description de la méthode. «P 1 : description,, P n : description» est l ensemble d arguments de la méthode, «InitPl» est le nom de la place initiale de la méthode et «GoalPls» est le(s) nom(s) de la(des) place(s) terminale(s) de la méthode. ( ) est la structure interne du service, une sorte de réseau prédicat/transition modifié, où : est un ensemble fini de places différent de l ensemble vide où désigne les places normales représentées par des cercles, l ensemble des places switch instanciées représentées par des ellipses et utilisées pour relier les G-Nets. Enfin, est l ensemble des places goal représentées par des cercles doubles utilisés pour représenter l état final de l exécution d une méthode. T est l ensemble des transitions. est l ensemble des arcs orientés, W (P T) (T P) (relation de flux). est une fonction qui associe une description à certains éléments de. [85]

103 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» est une fonction qui associe une condition (condition de garde) à certaines transitions, cette condition est une formule logique construite à partir de variables qui apparaissent dans les inscriptions des arcs entrants adjacents. est une fonction qui associe une action à certaines transitions, cette action est une suite d affectations de valeurs à des variables. * + est une fonction d étiquetage telle que O est un ensemble de noms d'opérations et τ est une opération silencieuse. Figure 4.2 : Exemple de G-Net services [86]

104 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Dans la figure 4.2, nous proposons un exemple illustratif de deux services client «Customer» et distributeur automatique de billets de banque «ACD» représentés par des G- Net services. Le service «Customer» reproduit le comportement d un client qui veut utiliser le distributeur automatique de billets de banque. Ce dernier assure les opérations de consultation de l avoir et du retrait d'espèces. Pour cela, il faut disposer d une carte magnétique valable et un code confidentiel. Pour effectuer toute opération, la carte en question doit être insérée dans la machine qui vérifie automatiquement sa validité. Dans l affirmatif, le client est alors invité à introduire son code confidentiel. Si le code introduit est accepté, la machine affiche un menu d opérations sur son écran. L'opération désirée est alors sélectionnée par le client en appuyant sur l'icône idoine. Deux cas sont à envisager: S il s agit d une demande d avoir, la machine affiche le solde du compte du client. Après quoi, elle réaffiche le menu d opérations. S il s agit d une demande de retrait de fonds, la machine affiche une fenêtre relative à cette opération permettant au client d introduire la somme à retirer. Après validation, la disponibilité du montant est automatiquement vérifiée par la machine. Si l avoir est insuffisant, elle le lui signifie par une indication sur l écran, la machine réaffiche le menu d opérations. En cas de disponibilité de fonds, elle lui distribue des billets de banque représentant la somme saisie. Si le code introduit est erroné, après trois tentatives successives la machine capture la carte. Il est à signaler que le client peut changer d avis et interrompre toute opération à tout moment avant sa validation. Le service «Customer» comporte une seul méthode «Client-operation» qui modélise le comportement du client. Tandis que le service «ACD» est constitué de cinq méthodes : «validity» : Elle permet de vérifier la validité de la carte magnétique. «code» : Elle permet de vérifier l exactitude du code confidentiel et de capturer la carte dans le cas de trois introductions successives d un code erroné. «display-op» : Elle permet d afficher le menu d opérations. «oper» : S il s agit d une opération de demande d avoir, elle permet d afficher le solde. Dans le cas d une demande de retrait de fonds, elle permet d afficher un tableau relatif à cette opération. [87]

105 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» «Withrawal» : Elle modélise l opération de retrait de fonds. Dans cet exemple, nous avons également utilisé plusieurs attributs : V : indique si la carte magnétique est valide ou non. C : indique si le code confidentiel est correct ou non. B : indique si la carte magnétique est bloquée ou non. A-exist : indique si la somme à retirer existe ou non dans le compte. N : représente le code confidentiel. A : représente le montant à retirer. OP : représente le type d opération (consultation de l avoir ou retrait d'espèces). I : représente le nombre d erreurs successives lors d introductions du code confidentiel (à chaque tentative incorrecte, la machine incrémente par un le nombre entier I. Si le code introduit est accepté par la machine, elle affecte la valeur zéro à I). La notation «ISP» représente le mécanisme principal pour spécifier l'interconnexion entre les différents G-Nets. Dans l'exemple de la figure 4.2, nous intégrons des places «ISP» avec les différentes méthodes du «ACD» (validity, code, display-op, oper et withdrawal) dans la structure interne (IS) de client «Customer» pour spécifier une relation client /serveur. 2.2 Les Services Web Un service web est un tuple ( ) où : est le nom du service utilisé comme son identificateur unique. est la description du service fourni. Elle donne un résumé des fonctionnalités offertes par le service. est le serveur où est localisé le service. est l'invocation du service web. est l ensemble de services composants du service web. Si * +, est un service atomique, sinon est un service composite. ( ) est le G-Net service modélisant le comportement dynamique du service web. [88]

106 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Parmi les différentes raisons qui justifient l utilisation des G-Nets dans la modélisation des services web nous pouvons citer : Les notations graphiques proposées par les G-Nets qui fournissent un moyen intuitif pour spécifier les services web en termes de modules qui favorisent l'abstraction et le couplage faible entre ces modules. le comportement de chaque module (G-Net) est décrit dans les bases des réseaux de Petri. L encapsulation est l un des concepts fondamentaux dans la technologie des services web. Contrairement à d autres types de réseaux de Petri de haut niveau tels que les réseaux de Petri colorés et les réseaux de Petri prédicats/transitions, les modèles G- Nets promeuvent l'encapsulation. Après avoir présenté les concepts de Service G-Net et Service web, nous montrons, dans la section suivante, comment les services Web peuvent être progressivement composés. Nous rappelons que nous utilisons les G-Net services comme un moyen pour offrir une algèbre de composition à la fois flexible et puissante. 3. Composition des services web La création d une application complexe distribuée peut être obtenue par la composition de services web. Etant donnés deux ou plusieurs services, chacun accomplissant une tâche spécifique, ils coopèrent parfois dans le but de réaliser une nouvelle tâche. Cette coopération se traduit par l obtention d un nouveau service à valeur ajoutée. Par exemple, un service de réservation d'hôtels peut collaborer avec un service web cartographie tel que Google Maps API pour permettre aux clients de situer l'emplacement des hôtels. La collaboration de ces services génère un service Web composé pouvant réaliser aussi bien les tâches individuelles originales qu une nouvelle tâche. Néanmoins, la composition des services web est loin d être une tâche triviale. Dans cette section, nous allons présenter une algèbre permettant de combiner des services web existants pour élaborer d autres services plus complexes. Nous considérons Séquence, Parallèle, Alternatif, Itération et Séquence Arbitraire comme constructeurs de base. Nous définissons également quatre constructeurs plus développés qui sont Discriminateur, [89]

107 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Sélection, Raffinement et Remplacement. Dans ce qui suit, nous donnons en premier lieu une définition informelle de chaque opérateur, puis nous donnons sa sémantique formelle en termes de G-Net services. 3.1 Les Constructeurs de composition Nous décrivons ci-dessous la syntaxe et la sémantique informelle des opérateurs de l'algèbre de composition. Ces derniers ont été choisis pour permettre des combinaisons simples et avancées de services web. La grammaire définissant l ensemble des services qui peuvent être générés en utilisant les opérateurs de l algèbre est décrite par la notation BNF suivante: ( ) tels que : ( ), - ( ) ε : est le service nul (ou service vide), c.à.d. un service qui n exécute aucune opération. X : est le service constant. Il consiste en un service exécutant une opération qui ne peut être divisée en sous opérations. Ce service est désigné par service atomique. : représente un service composite exécutant un service suivi immédiatement par un autre, c.à.d. est un opérateur de séquence. : représente un service composite pouvant reproduire le comportement de S1 ou S2 mais pas les deux, c.à.d. est un opérateur alternatif (opérateur de choix). : représente un service composite où un service est successivement exécuté plusieurs fois. est donc un opérateur d itération. : est un service composite exécutant une séquence arbitraire des services S1 et S2, c.à.d. est un opérateur de séquence arbitraire. : représente un service composite exécutant les deux services S1 et S2 en même temps et indépendamment l un de l autre. Le service résultant attend la fin d exécution de S1 et S2. // est donc un opérateur de parallélisme. ( ) : représente un service composite qui attend la fin d exécution d un service parmi les n-1 premiers services ( ) avant d'activer le service, c.à.d. ( ) est l opérateur discriminateur. [90]

108 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web», - : représente un service composite qui sélectionne et exécute un autre service parmi n services disponibles qui effectuent les mêmes tâches, c.à.d., un opérateur de sélection. ( ) : représente un service qui se comporte comme S à l'exception de l'opération étiquetée par «a», qui est remplacée par le bloc bien formé «A». Ce dernier est un réseau prédicat/transition modifié. c.à.d. raffinement. - est ( ) est un opérateur de ( ) : représente un service composite similaire à S sauf pour le service composant S1, qui est remplacé par le service non vide S2. c.à.d. opérateur de remplacement. () est un L algèbre proposée vérifie la propriété de fermeture. Cette dernière garantit que le produit de chaque opération est lui-même un service auquel peuvent être appliqués les opérateurs de l algèbre. Ainsi, par l agrégation et la réutilisation des services existants, et à travers des expressions déclaratives de l algèbre proposée, nous sommes en mesure de construire des services plus complexes. 3.2 Sémantique formelle Dans cette section, nous donnons une définition formelle des opérateurs de composition en termes de G-Net Services. GSP (S1) Attrs= {<Type>} Mtd= {[ ] (P 1 ) (P m )} GSP (S2) Attrs= {<Type>} Mtd= {[ ] (P 1 ) (P k )} GSP (Sn) Attrs= {<Type>} Mtd= {[ ] (P 1 ) (P r )} P 1 P 1 P P m P k P r Figure 4.3: Services S 1, S 2,, S n [91]

109 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Soient ( ) avec ( ) où ( ) pour i =1,, N : N services Web tels que et pour. Ces services sont représentés d une manière abstraite dans la figure 4.3 et servent d exemples pour la suite de cette section Service vide Le service vide, schématisé en figure 4.4, est un service n exécutant aucune opération. Il est utilisé pour des raisons techniques et théoriques. Définition : Le service vide est défini par as ( ) tel que: = vide. = «service web vide». = Null, indiquant qu'il n'y a pas de serveur pour le service. = Null, le service ne peut être invoqué. = {vide} ( ) où : ( ) avec ( ) GSP(vide) P Figure 4.4 : Service vide Séquence L opérateur Séquence permet la construction d un service composé de deux services exécutés l'un après l'autre. Ce constructeur est utilisé quand un service attend le résultat d exécution d'un autre avant de commencer sa propre exécution. Par exemple, lors d un achat en ligne, le service «Paiement» est exécuté après l'achèvement du service «Sélection d'articles». [92]

110 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» GSP(Seq) Attrs= {<Type>} Mtd.Seq= {[ ] (P 1 ) (P 3 )} P 1 ISP(S1) T 1 P 2 ISP(S2) T 2 P 3 Figure 4.5 : Service Définition : Le service est défini par ( ) tel que : est le nom du nouveau service. est la description du nouveau service. est la localisation du nouveau service (peut éventuellement être au niveau du même serveur que celui de l un des services composants). est l invocation du nouveau service.. ( ) où : ( ) avec : *, - ( )( )+, - ( ) avec: * + * + *( ) ( ) ( ) ( )+ * + * + * + {( ( )) ( ( )) ( )} [93]

111 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Une représentation graphique en termes de G-Net service du service composite figure 4.3. est illustrée par la figure 4.5. Il prend comme opérandes les deux services S1 et S2 de la Alternatif Etant donnés deux services S1 et S2, l opérateur alternatif reproduit soit le comportement de S1, soit celui de S2, mais pas les deux. Par exemple, le service «Identification» est suivi soit par le service «Autoriser-accès» soit par le service «Refuser-accès». GSP(Alt) Attrs= {<Type>} Mtd.Alt= {[ ] (P 1 ) (P 4 )} P 1 T 1 T 2 P 2 ISP(S1) ISP(S2) P 3 T 3 T 4 P 4 Figure 4.6 : Service Définition : Le service est défini par ( ) tel que : est le nom du nouveau service. est la description du nouveau service. est la localisation du nouveau service (peut éventuellement être au niveau du même serveur que celui de l un des services composants). est l invocation du nouveau service.. ( ) où : [94]

112 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» ( ) avec : *, - ( )( )+, - ( ) avec: * + * + *( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )+ * + * + * + *( ) ( ( )), ( ( )), ( )}. Etant donnés les deux services S1 et S2 de la figure 4.3, le service composite est représenté par le G-Net service de la figure Itération L'opérateur itération permet à un service S d être exécuté un certain nombre de fois. Un exemple d'utilisation de ce constructeur est quand un client commande à un service un produit un certain nombre de fois. GSP(Iter) Attrs= {<Type>} Mtd.Iter= {[ ] (P 1 ) (P 2 )} P 1 ISP(S1) T 1 T 2 P 2 Figure 4.7 : Service Définition : Le service est défini par ( ) tel que : est le nom du nouveau service. est la description du nouveau service. [95]

113 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» est la localisation du nouveau service (peut éventuellement être au niveau du même serveur que celui du service composant).. est l invocation du nouveau service. ( ) où : ( ) avec : *, - ( )( )+, - ( ) avec: * + * + *( ) ( ) ( ) ( )+ * + * + * + *( ( )), ( )}. Si l on considère le service S1 de la figure 4.3, le service service de la figure 4.7. est représenté par le G-Net Séquence arbitraire L opérateur séquence arbitraire spécifie l'exécution de deux services qui ne doivent pas être exécutés en même temps. Ce constructeur est utile quand il n'y a aucun intérêt à exécuter des services en parallèle. Par exemple, quand il n'y a pas de date limite pour accomplir une tâche globale et que le parallélisme engendre des coûts supplémentaires. GSP(Ar.seq) Attrs= {<Type>} Mtd.Ar.seq= {[ ] (P 1 ) (P 9 )} P 1 T 1 P 2 P 3 P 4 T 2 T 3 P 5 ISP(S1) ISP(S2) P 6 T 4 P 7 T 6 T 5 P 8 P 9 Figure 4.8 : Service [96]

114 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Définition : que : Le service est défini par ( ) tel est le nom du nouveau service. est la description du nouveau service. est la localisation du nouveau service (peut éventuellement être au niveau du même serveur que celui de l un des services composants). est l invocation du nouveau service.. ( ) où : ( ) avec : *, - ( )( )+, - ( ) avec: * + { } *( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )+ * + * + * + *( ) ( ) ( ) ( )( ) ( ) ( ( )),( ( )) ( )}. Etant donnés les deux services S1 et S2 de la figure 4.3, le service composite représenté par le G-Net service de la figure 4.8. est Parallèle Etant donnés deux services S1 et S2, l'opérateur parallèle construit un service composite exécutant les deux services (S1et S2) en parallèle. L'accomplissement du service résultant est atteint lorsque les deux services sont terminés. Ce constructeur est utile quand un service exécute plusieurs services d une façon indépendante. [97]

115 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» GSP (Par) Attrs= {<Type>} Mtd.Par= {[ ] (P 1 ) (P 4 )} P 1 T 1 P 2 ISP(S1) ISP(S2) P 3 T 2 P 4 Définition: Figure 4.9 : Service Le service est défini par ( ) tel que : est le nom du nouveau service. est la description du nouveau service. est la localisation du nouveau service (peut éventuellement être au niveau du même serveur que celui de l un des services composants). est l invocation du nouveau service.. ( ) où : ( ) avec : *, - ( )( )+, - ( ) avec: * + * + *( ) ( ) ( ) ( ) ( ) ( )+ * + * + * + *( ) ( ( )), ( ( )), ( )}. Etant donnés les deux services S1 et S2 de la figure 4.3, le service composite représenté par le G-Net service de la figure 4.9. est [98]

116 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Discriminateur L'objectif principal de l'opérateur discriminateur est d'accroître la fiabilité et d améliorer les délais des services à travers le web. Pour les clients, les meilleurs services sont ceux qui répondent en un temps optimal et sont constamment disponibles. Le constructeur composite obtenu en appliquant l'opérateur Discriminateur soumet des commandes redondantes à différents services effectuant la même tâche (S 1, S 2,, S n-1 par exemple). Le premier service qui répond à la requête active le service S n. Toute autre réponse tardive est ignorée. GSP (Disc) B= {Boolean} Mtd.Disc = {[ ] (P 1 ) (Pn +3 )} P 1 T 1 <B> B :=true P 2 ISP(S1) ISP(S2).. ISP(Sn-1) P n T 2 T 3 T n <B> B ==true B :=false P n+1 <B> T n+1 T n+3 B ==false ISP(Sn) P n+2 T n+2 P n+3 Figure 4.10 : Service ( ) Définition: Le service ( ) est défini par ( ) ( ) tel que : est le nom du nouveau service. [99]

117 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» est la description du nouveau service. est la localisation du nouveau service (peut éventuellement être au niveau du même serveur que celui de l un des services composants). est l invocation du nouveau service.. ( ) où : ( ) avec : {, - ( )( )}, -. ( ) avec: * + * + *( ) + *( ),( ) + *( ) ( ) ( ) ( )+ * ( ), - ( ), - ( ), -, }, * ( ), - ( ), - + * ( ), - ( ), - + {( ( )) + *( ) ( ) ( ( )), ( )}. Etant donnés les services S1, S2,, Sn de la figure 4.3, le service composite ( ) est représenté par le G-Net service de la figure Sélection Soit N services web (S1, S2,, Sn) fournissant différemment le même service. Ces derniers sont étendus par une méthode spécifique «req» qui reçoit, traite et répond à des requêtes (un exemple de ces services est représenté dans la figure 4.11). Select est un opérateur qui permet, après traitement des réponses, de choisir un service parmi tant d autres ayant tous répondu à la même requête. Cet opérateur offre la possibilité de profiter du meilleur service. Le choix est subordonné à plusieurs critères, par exemple, les meilleurs services de vente sont ceux qui présentent des prix alléchants et des délais de livraison raisonnables. [100]

118 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» GSP(Sm) resp= {String} Req= {[r: String] (P 1 ) (P 2 )} Mtd= {[ ] (P 3 ) (P q )} P 1 T 1 P 2 Return respons e P 3 Treat-req <resp> <resp>.. P q... Figure 4.11 : Service étendu GSP (select) J= {Integer}, r= {String} Mtd.select = {[ ] (P 1 ) ( P 2n+3 )} P 1 T 1 Create-request <r> <r> <r> <r> P 2 ISP(S1.req) ISP(S2.req).. ISP(Sn.req) P n+1 <resp> <resp> <resp> T 2 <resp> P n+2 Select_a_service (J :=m 1<=m<=n) <J> <J> <J> T 3 J==1 T 4 J==2 T n+2 J==n P n+3 ISP(S1.mtd) P n+4 ISP(S2.mtd).. P 2n+2 ISP(Sn.mtd) T n+3 T n+4 T 2n+2 P 2n+3 Figure 4.12 : Service, - [101]

119 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Définition: Le service, - est défini par, - ( ) tel que : est le nom du nouveau service. est la description du nouveau service. est la localisation du nouveau service (peut éventuellement être au niveau du même serveur que celui de l un des services composants). est l invocation du nouveau service.. ( ) où : ( ) avec : {, - ( )( )}, -. ( ) avec: * + * + * ( ) ( ) ( ) ( ) ( ) ( ) + *( ) ( )+ * ( ) ( ), - + * ( ), - + * ( ), - ( ), - + * ( ), - + * + * + *( ( )), ( ) ( ) ))+ *( ) ( ) ( )+. Etant donnés N services étendus (tel que le service représenter dans la figure 4.11), le service composite, - est représenté par le G-Net service de la figure Raffinement L opérateur de raffinement permet de remplacer certaines opérations du service par d'autres plus détaillées. Le raffinement est la transformation d un modèle d'une forme abstraite de haut niveau à une forme de niveau inférieur plus concrète, ce qui permet donc la modélisation hiérarchique. [102]

120 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» (S1) GSP(S1) Attrs= {<Type>} Mtd= {[ ] (P 1 ) (P q )} S==Ref (S1, a, A) GSP(S) P 1 P 1.. P q P i. a P a P b (A).. P a P b. P q Figure 4.13 : Exemple de raffinement Définition: Soient «S 1» un service web modélisé par un G-Net service, «a» un nom d opération et «A» un bloc bien formé sous la forme d un réseau prédicat/transition modifié. Le service ( ) est défini par ( ) ( ) tel que: est le nom du service raffiné. est la description du service raffiné. est la localisation du service raffiné (peut éventuellement être au niveau du même serveur que celui de ). est l invocation du service raffiné. * si ( )( ( ) ) sinon. ( ) où : ( ) avec : *, -( )( )+ si ( )( ) ( est la place initiale de S 1, est la place initiale de A et est la place goal de S 1 ). *, -( ) ( )+ sinon., - [103]

121 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» ( ) avec: ( ) ( ) ( ) si ( )( ( ) ) ( ) sinon. ( ) si ( )( ( ) ) ( ) sinon. * ( ) *( ) ( ) ( ) ( )( )+ {( ) ( ) ( ) + * ( ) ( ) ( ) + si ( )( ( ) ) ( ) sinon. * ( ) * ( ) ( ) ( ) ( ) ( ) ( )} { ( ) ( )( ) ( ) ( ) + * ( ) ( )( ) ( ) ( ) + si ( )( ( ) ) ( ) sinon. ( ) ( )( ( ) ) ( ) sinon. ( ) si ( )( ( ) ) ( ) sinon. ( ) *( ) ( )} si ( )( ( ) ) ( ) sinon. La figure 4.13 représente un exemple abstrait d une opération de raffinement Remplacement Cet opérateur permet de remplacer un service composant par un autre au sein d un service composé. L opérateur de remplacement permet de remédier au problème de la disponibilité, c.à.d. si un service n est plus disponible, il peut être remplacé par un autre assurant les mêmes fonctions. Il s agit ici de l équivalence de comportement. Définition: Le service ( ) est défini par ( ) ( ) tel que: est le nom du nouveau service. est la description du nouveau service. est la localisation du nouveau service (peut éventuellement être au niveau du même serveur que celui de ). est l invocation du nouveau service. *( ) sinon. [104]

122 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» ( ) où : ( ) avec : *, -( )( )+,, - ( ) avec: ( ) ( ) ( ) ( ) ( ) ( ) ( ) {( ( )) ( )} {( ( )) ( ) ( ( ))} si ( ) sinon. La figure 4.14 représente un exemple d une opération de remplacement. (S1) GSP(S1) Attrs= {<Type>} Mtd= {[ ] (P 1 ) (P s )} S==Rep (S1, s2, s3) GSP(S) P 1 P 1... ISP(S2) P g... ISP(S3) P g ISP(S2). P m P s ISP(S3). P m P s Figure 4.14 : Services et ( ) 4. Vérification formelle des services web La vérification formelle des services web est cependant primordiale afin d assurer la qualité et la fiabilité des services développés. Ceci est vital pour les entreprises. Un service web qui contient des erreurs peut causer des désagréments à l entreprise. [105]

123 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Dans la vérification formelle de la composition de services web, nous pouvons distinguer deux approches : La première approche se concentre sur la vérification de services composés déjà développés et exprimés dans des langages tels que BPEL ou WSCI. Dans cette approche le code du service composé est traduit dans un langage de spécification formelle. La deuxième approche utilise les techniques de vérification formelle dans l étape de spécification du cycle de développement, c.à.d. que la composition des services web est directement spécifiée à l aide d un langage de description formel avant la génération de code, ce qui garantit la justesse du service web composé. Yang et al. ont expliqué dans [109] que les réseaux de Petri permettent de vérifier des propriétés, chacune ayant une signification particulière dans le domaine de la composition des services. Parmi ces propriétés, on peut citer l atteignabilité, L étude des bornes, etc. Concernant les G-Nets, nous présentons dans ce qui suit deux techniques permettant la vérification formelle de ces modèles. 4.1 Une technique de vérification basée réseaux de Petri Prédicats/Transitions Les réseaux de Petri Prédicats/Transitions (PrT-Nets) sont une catégorie des réseaux de Petri de haut niveau. Ils permettent de spécifier des communications inter-systèmes avec passage de valeurs. Dans les PrT-Nets, les jetons sont munis d opérations et de relations et sont structurés par des n-uplets de valeurs, les transitions sont remplacées par des règles dans une logique de premier ordre [12]. Les transitions sont sensibilisées par une famille d événements au lieu d un seul événement comme les réseaux de Petri ordinaires. Les arcs sont dénotés par une variable au lieu d une valeur. Afin d analyser et de vérifier les spécifications G-Nets, Deng et al. Ont proposé dans [11] une technique de transformation qui permet de convertir un modèle G-Net en un ensemble de modèles PrT-Nets équivalents. L objectif de cette transformation est d appliquer les techniques d'analyse formelle des PrT-Nets sur les spécifications G-Nets. La figure 4.15 schématise l idée de base de la technique de transformation d une spécification G-Net en un modèle PrT-Net équivalant. Pour plus de détails voir [11]. [106]

124 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Pf P T_P Pl i. Transformation d une place de G-Net P 1 P 2 P 1 l P 2 l T T P 3 P 4 P 3 f P 4 f ii. Transformation d une transition de G-Net ISP(G ) Pf P 2 T 2 T 3 P 3 T 1 T4 Pl Ps Pf S des places initiales Pl S des places finales de G de G G.IS iii. Transformation d une place ISP Figure 4.15 : Principes de transformation des G-Nets vers PrT-Nets [107]

125 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Cette technique a été automatisée par Kerkouche et al. dans [110] tout en utilisant l outil de transformation de graphes AToM 3. L un des analyseurs les plus utilisés pour les PrT-Nets est PROD 1 qui est un outil textuel d analyse d atteignabilité, Le langage de description des modèles PrT-Nets en PROD est le langage C étendu par des directives permettant de décrire les réseaux de Petri. La génération automatique de la description PROD a été présentée dans [108], les auteurs ont toujours utilisé l outil AToM 3 pour générer un fichier texte qui contient une description PROD à partir d un modèle PrT-Net donné. Cette description est compilée par l analyseur PROD afin d obtenir un programme exécutable qui génère le graphe d atteignabilité du modèle PrT-Net. Dans un premier temps, nous avons réutilisé cette technique dans le but de vérifier formellement les services web en utilisant l analyseur PROD [111]. Par la suite, nous avons constaté que cette technique a des inconvénients. L'un des problèmes relié à cette méthode est la duplication des places. Ce problème peut facilement être observé dans l'exemple que nous allons présenter dans le prochain chapitre. En plus, pour qu on puisse utiliser cet analyseur pour les G-Nets il faut passer par deux étapes : la première c est celle de la transformation des modèles G-Nets vers des modèles PrT-Nets, et la deuxième étape consiste en la génération des descriptions PROD à partir des modèles PrT-Nets résultants. Il est à signaler aussi que PROD ne dispose pas d une interface graphique qui facilite son utilisation. En plus, le manque d un fichier exécutable rend l installation du PROD une tache un peu difficile. Enfin, PROD n est pas à jour pour fonctionner par exemple sur Windows Une technique de vérification basée Maude Pour éviter les problèmes liés à la première technique, nous avons proposé une autre approche de transformation M2T qui permet de translater un modèle G-Net à une spécification Maude équivalente dans le but d entreprendre la vérification formelle d un plus grand nombre de propriétés vu que Maude dispose d une batterie intéressante d outils de vérification formelle [112]. Afin de produire des spécifications Maude équivalentes aux modèles G-Net services nous avons proposé d abord un module fonctionnel qui décrit les opérations de base d'un G-Net service, ce module est le suivant : 1 [108]

126 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» fmod G-Net-Service is protecting STRING. sorts Place Marking List Operation-name. subsort Operation-name < String. op nil : -> List. op : Universal List -> List [ctor poly (1)]. op em : -> Marking. op <_;_> : Place List -> Marking. op _._: Marking Marking -> Marking [assoc comm]. op So : -> Operation-name. op L : Place -> Operation-name. endfm Comme illustré dans le code ci-dessus, nous avons créé une liste hétérogène dans le but de représenter les différentes variables d un G-Net service. «em» dénote le marquage vide dans un G-Net service. L'opération «<_;_>» permet la construction des marquages élémentaires. Le premier paramètre de cette opération est une place et le second est une liste qui contient les variables du G-Net service. L opération L permet d associer à chaque place de G-Net service un «nom d opération». L opération «_._» implémentant l opération Le processus de génération de la spécification Maude à partir d un modèle G-Net service peut être divisé en cinq étapes séquentielles comme suit : Première étape : Cette étape permet de créer l entête du module système spécifiant le G-Net service en question. C.à.d. «mod (nom de GSP) is». Deuxième étape : Cette étape permet d importer les différents modules utilisés par le module au cours de la génération. L importation du module G-Net-service est obligatoire. Les autres modules sont soit des modules prédéfinis qui offrent des types de données couramment utilisés dont nous pouvons citer (BOOL, STRING, INT, etc.), soit des modules spécifiant d autres G-Net services invoqués par le G-Net service en question. [109]

127 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» La troisième étape : Cette étape permet de décrire les différentes places de G-Net service et d associer à chacune d entre elles un «non d opération» en utilisant l opération «L» définie dans le module importé «G-Net-service». Les noms des places sont de la forme : «(nom de GSP)-(nom de la place)». La quatrième étape : cette étape permet d extraire les différentes variables utilisées par le G-Net service. les variables en Maude sont déclarées avec cette syntaxe : «var (le nom de la variable) : (sa sorte)». Pour déclarer plusieurs variables de la même sorte on peut utiliser «vars» au lieu de «var» suivit par les noms des variables séparés par des espaces. La cinquième étape : Cette étape permet d associer à chaque transition de G-Net service une règle de réécriture. Cette dernière peut être conditionnelle ou inconditionnelle. Une règle conditionnelle a la forme suivante : crl [(nom de GSP)-(nom de la transition)] : marking => marking if (la condition associée à la transition). La forme d une règle inconditionnelle est rl [(nom de GSP)-(nom de la transition)] : marking => marking. soit pl P et tr T, la partie gauche de la règle de réécriture étiquetée par [(nom de GSP)-tr] est construite à partir des marquages de la forme {< (nom de GSP)-pl; (la liste hétérogène contenant les variables utilisées par le G-Net service) > (pl, tr) pl tr pl.type!=isp} en utilisant l opération (.) définie dans le module «G-Netservice». La même chose pour la partie droite de cette règle qui est construite à partir des marquages de la forme {< (nom de GSP)-pl; (la liste hétérogène contenant les variables utilisées par le G-Net service) > (tr, pl) W pl tr pl.type!=isp} en utilisant la même opération(.). Dans le cas où pl.type=isp: Si (pl tr) dans ce cas la transition «tr» sera reliée directement avec la place goal (ou les places goal) de la méthode invoquée par la place «pl». Si (pl tr ) dans ce cas la transition «tr» sera reliée directement avec la place initiale (ou les places initiales) de la méthode invoquée par la place «pl». Enfin, après la création de toutes les règles de réécriture, il faut ajouter le mot clé «endm» à la fin de la spécification Maude générée. W [110]

128 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Le choix de Maude est justifié par plusieurs raisons dont nous pouvons citer : Maude est un langage formel de spécification et de programmation déclarative. Il est basé sur une théorie mathématique solide de la logique de réécriture. Maude est multi paradigme, il supporte la programmation orientée objet, fonctionnelle ainsi que la spécification formelle des system orientés objet. Ce qui rend la translation des modèles G-Net services vers des spécifications Maude équivalentes facile et flexible. Maude inclut un certain nombre de modules prédéfinis permettant de faciliter la tâche de spécification. Un autre aspect qui favorise l utilisation du langage Maude dans la spécification des systèmes est la présence d un ensemble d outils basés Maude permettant de faciliter grandement la tâche de vérification, parmi ces outils nous pouvons citer : inductive theorem prover (ITP) Maude LTL Model Checker Maude termination tool (MTT) Maude coherence checker (MCC) L environnement Maude est très versatile en matière de simulation. Il permet de sélectionner une configuration initiale personnalisée pour une simulation, ce qui permettra de vérifier une partie du système de façon à ne pas compromettre ce qui a déjà été fait. En outre, plusieurs travaux ont été proposés dans le but de transformer d autres types de réseaux de Petri de haut-niveau vers des spécifications Maude. Nous pouvons citer : le travail de Boudiaf et Djebbar qui ont automatisé le processus de transformation des réseaux de Petri colorés vers des spécifications Maude équivalentes [113]. 5. Conclusion Dans ce chapitre, nous avons présenté une approche à la fois simple et puissante pour la modélisation, la composition et la vérification formelle des services web. Cette approche a l avantage majeur de bénéficier de l aspect formel, modulaire et orienté objet des G-Nets. En effet, la modélisation fondée sur les G-Nets permet la spécification et le prototypage de services web complexes. [111]

129 Chapitre 4 : «Une approche intégrée G-Nets / Maude pour la modélisation, la composition et la vérification des services web» Une algèbre basée sur les G-Nets pour la composition des services web a été développée. Dans cette optique, nous définissons la sémantique formelle des opérateurs de composition par le biais des G-Net services. Concernant la vérification formelle des services web : Dans un premier temps, nous avons réutilisé une technique permettant de transformer les modèles G-Net vers des modèles PrT-Nets équivalents dans le but d appliquer les techniques d'analyse formelle des PrT-Nets sur les spécifications G-Nets. Dans un deuxième temps, nous avons proposé une autre approche de transformation M2T qui permet de translater un modèle G-Net service à une spécification Maude équivalente. L objectif de cette transformation est de bénéficier des différents outils de simulation et de vérification basés Maude. [112]

130 Chapitre 5 Implémentation et étude de cas

131 Chapitre 5 : «Implémentation et étude de cas» 1. Introduction Après avoir exposé l approche de modélisation, de composition et de vérification des services web, nous allons à présent décrire la phase de réalisation relative à cette dernière. Nous allons donc présenter dans ce chapitre un outil Java incluant les différentes fonctionnalités de modélisation, de composition des services web et de génération des spécifications Maude équivalentes aux modèles G-Net services utilisés. Nous aborderons quelques détails techniques correspondant à l implémentation. Pour terminer, Nous présenterons un exemple qui nous permettra d illustrer l utilisation de notre outil. 2. Outils technologiques utilisés Dans cette section, nous présentons le langage de programmation utilisé pour la réalisation, l environnement de développement ainsi que l outil permettant la visualisation graphique des différents modèles G-Net services manipulés par notre application. 2.1 Langage de programmation Le langage utilisé pour la réalisation de notre outil est le langage orienté objet «Java» qui a été créé à la fin des années 80 lorsque bill Joy, cofondateur de Sun Microsystems en 1982, commença à imaginer un nouveau langage. Ceci incita un groupe de programmeurs de Sun Microsystems en l occurrence : James Osling,Patrick Naughton et Mike Sheridan à développer un langage de programmation qu ils ont baptisé OAK dans un premier stade pour prendre par la suite en janvier 1995 le nom JAVA qui veut dire café en argot American. Ce langage a été présenté officiellement le 23 mai 1995 au Sun World, après quoi plusieurs autres versions plus améliorées ont été réalisées par la maison Sun. La société Sun a été ensuite rachetée en 2009 par la société Oracle qui détient et maintient désormais Java. Notre choix s est posé sur ce langage compte tenu des multiples avantages qu il offre, entre autres : Java est un langage dynamique, simple et robuste. La sémantique du langage Java est indépendante de la plateforme. Donc un programme écrit en Java fonctionne de manière indépendante de l architecture matérielle. [113]

132 Chapitre 5 : «Implémentation et étude de cas» Les logiciels développés avec le langage Java sont facilement portables sur plusieurs systèmes d exploitation tels que : UNIX, Microsoft Windows, Mac OS. Java reprend en grande partie la syntaxe du langage C++, très utilisé par les informaticiens. Néanmoins, Java a été épuré des concepts les plus subtils du langage C++ et à la fois les plus déroutants, tels que l héritage multiple qui a été remplacé par les interfaces. Les concepteurs ont privilégié l approche orientée objet de sorte qu en Java, tout est objet à l exception des types primitifs (nombres entiers, nombres à virgule flottante, etc.). Java a donné naissance à un ensemble d environnements de développement (Eclipse, Netbeans, etc.), des machines virtuelles (MSJVM, JRE) applicatives multi-plateformes (JVM), une plateforme java de base (java SE) avec des API pour la création des interfaces graphiques (AWT, Swing). La portabilité du code Java est assurée par la machine virtuelle. 2.2 Environnement de développement L environnement de programmation utilisé pour le développement de l outil est «Eclipse», qui nous a apparu comme étant l environnement le plus approprié pour la réalisation de notre application grâce aux facilités qu il offre. Ainsi, Eclipse intègre : La gestion basique des projets et codes Java purs avec interfaces graphiques. La gestion des diagrammes UML de toutes sortes. La gestion des paquetages et déploiement d applications. La gestion de différents serveurs et bases de données, etc. En plus, Eclipse est un environnement de développement multi-langages, extensible et polyvalent. 2.3 Affichage graphique Pour représenter les modèles G-Net Services, nous avons fait appel à l outil «dotty». Ce dernier est un éditeur graphique de la suite «Graphviz 1», développé par «AT&T 2». Il peut être utilisé comme un éditeur autonome, ou comme un module pour les applications qui manipulent des graphes. 1 http :// 2 http :// [114]

133 Chapitre 5 : «Implémentation et étude de cas» «dot» est le langage supporté par «dotty». Il permet de décrire de façon simple un graphe (une liste de nœuds et une liste d'arcs pour les relier). Les nœuds des graphes sont organisés de manière hiérarchique. «dotty» lit un fichier au format «dot», le compile, et dessine le graphe correspondant. L'algorithme de dessin repère l'ensemble des arcs qui ont la même direction (de haut en bas, de gauche à droite) et minimise (par programmation linéaire) les croisements entre les arcs et leur longueur. Dans notre outil, nous avons créé un module qui permet de générer automatiquement des fichiers (.dot) représentant les différents modèles G-Net services utilisés (soit des modèles spécifiés par l utilisateur, soit des modèles résultants d une opération de composition). Un appel système à l outil «dotty» permet donc de visualiser ces modèles. 3. Implémentation Afin d automatiser le processus de modélisation, de composition des services web et de génération des spécifications Maude, nous avons proposé dans un premier temps un métamodèle pour les G-Net services, après quoi nous avons développé une application Java en nous basant sur ce méta-modèle et sur l ensemble des règles de composition que nous avons précédemment formellement défini. Nous avons automatisé également le processus de transformation des modèles G-Net services vers des spécifications Maude équivalentes. Concernant la méta-modélisation, nous avons utilisé le modèle de diagramme de classes d UML comme méta-formalisme. Notre méta-modèle est composé de sept classes comme le montre la figure 5.1. Classe «G-Net»: Elle construit le modèle G-Net service final à partir de la place spéciale générique (GSP) et de la structure interne (IS). Classe «GSP»: Elle représente la place spéciale générique de G-Net service, elle possède trois attributs, le premier est un attribut clé «name», cependant les deux autres sont des listes. La première liste «AS» contient les attributs du G-Net service et la deuxième liste «MS» contient l ensemble de méthodes du G-Net service. Classe «IS» : Elle représente la structure interne du G-Net service. Elle est composée d un ensemble de nœuds (places et transitions) reliées par des arcs. [115]

134 Chapitre 5 : «Implémentation et étude de cas» Classe «Node» : Elle représente les différents nœuds du G-Net service, elle possède un attribut clé «name» qui représente le nom du nœud. C est une superclasse de deux classes «Place» et «Transition». Classe «Place» : Elle représente les places du G-Net service. Elle possède cinq attributs : «operation-name»: Il représente le nom d opération associé à la place. «tokens»: Il représente les jetons du G-Net service supportés par la place. «type»: Il indique le type de la place (place normale, place goal ou place ISP). «invokedgnet»: Il est utilisé seulement si la place est de type ISP, il représente le nom du G-Net service à invoquer. «usingmethode»: Il est utilisé seulement si la place est de type ISP, il représente le nom de la méthode à invoquer. «usingmethode» est l une des méthodes du G-Net service «invokedgnet». Classe «Transition» : Elle représente les transitions du G-Net service. Elle possède deux attributs : «condition» et «action». Classe «Arc» : Elle représente les arcs du G-Net service. Elle possède un attribut «inscription» qui représente la description de l arc. Figure 5.1 : Méta-modèle des G-Net services [116]

135 Chapitre 5 : «Implémentation et étude de cas» La contrainte OCL: (context Arc inv: (self.source.ocliskindof(transition) and self.target.ocliskindof(place)) or (self.source.oclis-kindof(place) and self.target.ocliskindof(transition))) assure que les arcs ne relient que des places vers des transitions ou vice versa. L application développée permet de spécifier des services web en termes de G-Net services, de les sauvegarder, de les modifier, de les composer et de les transformer vers des spécifications Maude équivalentes L une des fonctionnalités principales de l application est celle de la composition. Cette dernière prend en entrée un service ou un ensemble de services sur lesquels elle applique une opération ou une suite d opérations pour retourner un service composé ou raffiné comme résultat. La composition des services web modélisés par des G-Net services peut être vue comme étant une approche de transformation de graphe endogène où : Les modèles sources et le modèle cible sont conformes aux même méta-modèle. Les différents opérateurs de l algèbre de composition constituent les règles de la grammaire de graphes Le scénario de la composition est représenté dans la figure ci-dessous. Méta-modèle des G-Net services sources Conforme à Conforme à Modèles G-Net services sources Lit Moteur de Composition Produit Modèle G-Net service cible Exécute Opérateurs de composition Figure 5.2 : Scénario de la composition [117]

136 Chapitre 5 : «Implémentation et étude de cas» Une autre fonctionnalité de notre application est celle de la génération des spécifications Maude. Cette dernière permet de transformer un modèle G-Net service en une spécification Maude équivalente. Le scénario de la transformation est représenté dans la figure ci-dessous. Méta-modèle des G-Net services sources Règle de transformation Conforme à Exécute Modèle G-Net service Lit Moteur de transformation Produit Spécification Maude équivalente Figure 5.3 : Scénario de la génération des spécifications Maude Actuellement ce n est pas seulement le fonctionnement de l application qui attire l utilisateur, mais aussi la qualité de l interface. Pour cela nous avons essayé de fournir des interfaces qui ajoutent à l application un certain dynamisme, tout en respectant l aspect ergonomique. La figure 5.4 représente la fenêtre principale de notre outil. Figure 5.4 : Fenêtre principale de l application [118]