FR 2838902 A1 20031024 FR 0205080 A 20020423 par suppression de ladite modulation. PROCEDE SIMPLIFIANT L'ACCES A DES DONNEES HETEROGENES GEREES PAR DES OUTILS LOGICIELS La presente invention se rapporte a un procede simplifiant l'acces a des donnees heterogenes gerees par des outils logiciels. L' invention est m ise en ceuvre dans le domaine des outils d'ingenierie logiciels. Ces outils peuvent etre de differents types: outils de modelisation, generateurs de code, outils de test,... Les donnees utilisees par ces outils vent representees dans un format proprietaire, qui est different d'un outil a l'autre. II en resulte que les donnees presentes dans un outil ne peuvent pas etre utilisees directement par un autre outil. Pour permettre a un outil d'exporter ses donnees vers un outil d'un autre type, on procede actuellement de deux fa,cons differentes: par liaison manuelle ou par liaison point-a-point. La liaison manuelle s'applique lorsque l'outil emetteur de donnees peut exporter ses donnees dans un format acceptable par le receveur. II faut alors proceder en deux phases, comme schematise en figure 1. Dans un premier temps t1, on lance l'outil exportateur OU-1, et on lui fait produire un fichier d'export F1 approprie (t'1). Dans un deuxieme temps (t2), on lance le deuxieme outil OU-2 (outil recepteur) recevant (t'2), comme parametre de travail, le fichier F1 precedemment exporte. Le resultat final R est alors elabore par l'outil OU-2 (t3). II est possible que le premier outil ne puisse pas exporter les don nees demand ees au niveau de gran u larite ou au format souhaite par le deuxieme outil, ce qui impose alors une phase intermediaire de traitement du fichier d'export F1. Les inconvenients majeurs de ce procede vent le manque d'automatisation et le risque d'erreur d'utilisation au niveau du fichier d'export, qui peut par exemple etre celui genere lors d'un export anterieur. Selon le procede connu de liaison point-a-point, on utilise une interface specifique aux deux outils. Comme schematise en figure 2, un adaptateur de l'outil demandeur de donnees OU-3 appelle directement (t1) I'interface de programmation ( >) IP-1 de l'outil OU-4 possedant les donnees, qui produit (t2) le fichier d'export F2 demande. L'outil fournisseur OU-4 envoie alors (t3) un acquittement a l'outil appelant OU-3, qui peut chercher (t4) le fichier exporte et l'utiliser (t5) pour fabriquer le produit P. par exemple. L'inconvenient de ce procede est que chaque liaison entre outil fournisseur et outil client doit faire ['objet d'une realisation specifique. Par exemple, pour un meme outil fournisseur de donnees pour cinq outils utilisateurs il faut realiser cinq interfaces distinctes, I'intelligence de chaque interface se situant du cote du client. Les ateliers de developpement faisant appel a de tres nombreux couplages entre outils, il en resulte que les coGts de developpement des couplages, et surtout leurs coOts de maintenance, peuvent rapidement devenir tres importants. En outre, tout outil evolue dans le temps, ce qui entrane des changements de ses fonctionnalites. II devient done indispensable de faire evoluer chacun de ses couplages a d'autres 1 o outils. La presente invention a pour objet un procede simplifiant l'acces a des donnees heterogenes gerees par des outils logiciels, procede qui permet l'automatisation des echanges, qui evite les erreurs d'utilisation de fichiers d'export, qui ne soit pas dependent du type de liaison etablie entre outil fournisseur et outil client, dont les coOts de developpement et de maintenance solent le plus faible possible, et qui permette ['evolution des outils concernes sans necessiter de faire evoluer tous les couplages associes. Le procede conforme a ['invention est caracterise en ce que l'on etablit pour chaque outil une grammaire formelle d'identification de ses granules, que l'on constitue pour chaque outil un serveur de granules interface avec lui et que l'on constitue pour chaque outil un client se connectant directement au serveur de granules approprie. La presente invention sera mieux comprise a la lecture de la description detaillee d'un mode de realisation, pris a titre d'exemple non limitatif et illustre par le dessin annexe, sur lequel: - les figures 1 et 2 mentionnees ci-dessus, vent des diagrammes servant a expliquer les procedes de l'art anterieur; - la figure 3 est un diagramme exposant l'etape d'identification de granules du procede de ['invention; - la figure 4 est un bloc-diagramme d'une architecture a deux outils mettant en ceuvre le procede de ['invention; et - la figure 5 est un diagramme exposant la creation d'une URL pour etablir une communication entre outils selon le procede de I'invention. Pour pouvoir creer un moyen universe! d'acces aux donnees d'un outil, le procede de ['invention comporte une premiere etape de definition d'une grammaire formelle des granules ( > en anglais, ou objets elementaires) geres par un outil. Par exemple, comme schematise en figure 3, les granules geres par un outil 1 de modelisation UML sont, dans l'ordre decroissant de taille, les projets 2 (projets individuals, produits) qui peuvent contenir chacun des types de diagrammes 3 (type sequences, type classes,.. .), qui peuvent eux-memes contenir des classes 4 (classes elementaires, relations entre classes,...), qui, a leur tour, peuvent contenir des attribute 5 (caracteristiques physiques,...). Cette grammaire permet de savoir a quel niveau de granularite 2 a 5 se trouvent les donnees requises par l'outil appelant et de definir sans ambigute les granules dans leur contexte. Pour permettre a un outil fournisseur de donnees d'interpreter correctement une requete provenant d'un outil appelant quelconque, I'invention prevoit de munir cet outil fournisseur d'un adaptateur (serveur de granules) qui est interface avec lui au moyen d'une API, qui est une interface bien connue en soi. Les roles de l'adaptateur vent les suivants: il decode les requetes des outils appelants, ces requetes respectant la grammaire formelle de 1'outil fournisseur; il va chercher le granule demande par l'intermediaire de ['interface de programmation API de l'outil; et il presente ce granule dans un format standardise permettant son utilisation par l'outil appelant. Ce format est par exemple le format XML, lorsque les donnees correspondantes vent des donnees structurables. Du cote de l'outil appelant, I'adaptateur est charge de: construire les requetes vers les outils fournisseurs de donnees; et 30. de decoder les reponses aux requetes, en lancant par exemple une copie par FTP a partir d'une adresse de fichier fournie dans la reponse. On a represente en figure 4 un exemple d' implementation d'adaptateur sur deux outils 6, 7 communiquant par 1'intermediaire d'un bus 8 de reseau informatique. La memoire 6A de l'outil 6 stocke ses donnees sous un format proprietaire F. L'outil 6 comporte une API 9, et on lui connecte un adaptateur 10. Cet adaptateur 10 peut ne comporter qu'une partie ' S si l'outil 6 n'est pas prevu pour etre un outil appelant, mais dans la majorite des cas, I'adaptateur comportera avantageusement une partie > S et une partie > C. De meme, I'outil appelant 7 comporte une API 11 et un adaptateur 12 constitue d'une partie > S. et, le cas echeant, d'une partie > S. Pour obtenir des granules de donnees detenues par l'outil 6, le client de l'adaptateur 12 de l'outil 7 adresse une requete 13 a l'outil 6 par I'intermediaire du bus 8. Cette requete 13 est au format standard URL ( >). Par le bus 8, la requete parvient (14) a la partie ' de l'adaptateur 10, qui commande a ltoutil 6 de selectionner dans sa memoire 6A le granule de donnees au niveau requis et de produire un fichier d'export XML 15A. Un acquittement 15 est transmis par I'adaptateur 10 vers le bus 8. Apres avoirtransite sur le bus 8, I'acquittement parvient (16) a l'adaptateur 12, qui l'interprete. Si necessaire l'adaptateur 12 fabrique une copie locale du fichier XML par FTP. II demande alors a l'outil 7 de transformer le fichier XML, par exemple, en code C ou Ada (17). On a schematise en figure 5 le format URL d'une requete. Ce format est le format standard URL, de la forme: http:// : / ? Dans ce format, on a: : / =nom de l'ordinateur cible: port de communication/nom de l'outil cible etona: ? >, le nom de l'outil en question (outil fournisseur) est ,, le nom du port de communication est > et ['etiquette > se decompose ainsi: >: commande >: nom du projet >: type de diagramme >: nom du diagramme >: nom de la classe lo >: nom de l'attribut La requete est done une demande d'export d'un attribut > de la classe > du diagramme d'activite >, qui fait partie du projet . Par consequent, I'utilisation d'une URL standard permet d'utiliser le protocole classique de communication HTTP ou HTTPS ( ) pour ['ensemble des transactions de controle entre client et serveur (requete de granules et acquittement de la requete par l'outil fournisseur). L'acquittement positif du serveur de l'adaptateur fournisseur contient en outre l'adresse d'un fichier dans lequel se trouve le resultat attendu. Le client de l'outil appelant peut alors en disposer a sa guise en lancant par exemple une copie locale par FTP. La combinaison d'URL formees a partir d'une grammaire specifique a chaque outil et d'un adaptateur specialise charge d'extraire les granules souhaites permet d'eviter l'emploi de formats de donnees heterogenes. Chaque outil fournisseur de donnees, combine a son adaptateur, se comporte done comme un serveur de donnees parfaitement standardisees. Chaque outil utilisateur (outil appelant) est dote d'un adaptateur qui est parfaitement independent des outils appeles (outils fournisseurs). Cet adaptateur est charge de formuler des demandes de granules avec un format standard d'URL base sur la grammaire publique de l'outil appele, et de decoder les reponses faites par l'outil appele. L'avantage immediat du procede de ['invention est le coOt limite du developpement, et surtout de la maintenance des couplages entre outils. Sauf changement de sa grammaire, ce qui est rare, I'evolution des fonctionnalites ou de ['implementation d'un outil fournisseur de donnees n'implique que la modification de son adaptateur. Dans le cas classique de la liaison point-a-point, la meme evolution de l'outil entranerait la modification de 1'ensemble des adaptateurs des outils appelants. Pour la mise en oeuvre du procede de ['invention, on ecrit les adaptateurs de preference en langage JAVA, afin d'assurer une portabilite maximale sur differentes plates-formes materielles et logicielles. Ces adaptateurs vent lies par une relation client-serveur classique. Selon un l o mode de mise en oeuvre avantageux, on exprime les grammaires des differents outils en langage XML. En resume, les requetes echangees vent en format HTML, ce qui est simple a mettre en oeuvre et fournit un support naturel pour les URL. Le protocole associe est le protocole HTTP, qui est simple, universe! et efficace. Pour le transfert des fichiers d'echange, le protocole utilise peut etre FTP. Chaque adaptateur d'outil implemente sa partie d'un protocole clientserveur. La mise au point ( > en anglais) peut etre effectuee a ['aide d'un navigateur classique, > par exemple. REVENDICATIONS 1. Procede simplifiant l'acces a des donnees heterogenes gerees par des outils logiciels, caracterise par le fait que l'on etablit pour chaque outil (6, 7) une grammaire formelle d/identification de ses granules, que l'on constitue pour chaque outil un serveur (10, 12) de granules interface (9, 11) avec lui et que l'on constitue pour chaque outil un client (C) se connectant directement au serveur (S) de granules approprie. 2. Procede selon la revendication 1, caracterise par le fait que la liaison entre client et serveur se fait selon le protocole HTTP. 3. Procede selon la revendication 1, caracterise par le fait que la liaison entre client et serveur se fait selon le protocole FTP. 4. Procede selon la revendication 1, caracterise par le fait que la liaison entre client et serveur se fait selon le protocole HTTPS. 5. Procede selon l'une des revendications precedentes, caracterise par le fait que le format des granules est du XML lorsque les donnees correspondantes vent des donnees structurables.