FR 2861476 A1 20050429 FR 0312489 A 20031024 PROCEDE D'ADRESSAGE UNIVERSEL DE GRANULES LOGICIELS POUR LA SIMPLIFICATION DE L'ACCES A DES DONNEES HETEROGENES GEREES PAR DES OUTILS LOGICIELS La présente invention se rapporte à un procédé d'adressage universel de granules logiciels pour la simplification de l'accès à des données hétérogènes gérées par des outils logiciels. L'invention est mise en oeuvre en particulier dans le domaine des outils d'ingénierie logiciels. Ces outils peuvent être de différents types: outils de modélisation, générateurs de code, outils de test,... Les données utilisées par ces outils sont représentées dans un format propriétaire, qui est différent d'un outil à l'autre. Il en résulte que les données présentes dans un outil ne peuvent pas être utilisées directement par un autre outil. Pour permettre à un outil d'exporter ses données vers un outil d'un autre type, on procède actuellement de deux façons différentes: par liaison manuelle ou par liaison point à point. La liaison manuelle s'applique lorsque l'outil émetteur de données peut exporter ses données dans un format acceptable par le receveur. Il faut alors procéder en deux phases, comme schématisé en figure 1. Dans un premier temps t1, on lance l'outil exportateur OU-1, et on lui fait produire un fichier d'export FI approprié (t'1). Dans un deuxième temps (t2), on lance le deuxième outil OU-2 (outil récepteur) recevant (t'2), comme paramètre de travail, le fichier FI précédemment exporté. Le résultat final R est alors élaboré par l'outil OU-2 (t3). Il est possible que le premier outil ne puisse pas exporter les données demandées au niveau de granularité ou au format souhaité par le deuxième outil, ce qui impose alors une phase intermédiaire de traitement du fichier d'export FI. Les inconvénients majeurs de ce procédé sont le manque d'automatisation et le risque d'erreur d'utilisation au niveau du fichier d'export, qui peut par exemple être celui généré lors d'un export antérieur. Selon le procédé connu de liaison point à point, on utilise une interface spécifique aux deux outils. Comme schématisé en figure 2, un adaptateur de l'outil demandeur de données OU-3 appelle directement (t1) l'interface de programmation ( API ) IP-1 de l'outil OU-4 possédant les données, qui produit (t2) le fichier d'export F2 demandé. L'outil fournisseur OU-4 envoie alors (t3) un acquittement à l'outil appelant OU-3, qui peut chercher (t4) le fichier exporté et l'utiliser (t5) pour fabriquer le produit P, par exemple. L'inconvénient de ce procédé est que chaque liaison entre outil fournisseur et outil client doit faire l'objet d'une réalisation spécifique. Par exemple, pour un même outil fournisseur de données, pour cinq outils utilisateurs, il faut réaliser cinq interfaces distinctes, l'intelligence de chaque interface se situant du côté du client. Les ateliers de développement faisant appel à de très nombreux couplages entre outils, il en résulte que les coûts de développement des couplages, et surtout leurs coûts de maintenance, peuvent rapidement devenir très importants. En outre, tout outil évolue dans le temps, ce qui entraîne des changements de ses fonctionnalités. II devient donc indispensable de faire évoluer chacun de ses couplages à d'autres outils. On connait d'après le brevet français 2 838 902 un procédé simplifiant l'accès à des données hétérogènes du type précité, qui n'est pas dépendant du type de liaison établie entre outil fournisseur et outil client, et qui permet l'évolution des outils concernés sans nécessiter de faire évoluer tous les couplages associés. Selon ce procédé connu, on établit pour chaque outil une grammaire formelle d'identification de ses granules, on constitue pour chaque outil un serveur de granules interfacé avec lui et on constitue pour chaque outil un client se connectant directement au serveur de granules ( Artifacts en anglais, ou objets élémentaires) approprié. Les granules ont trois caractéristiques: 1. L'hétérogénéité On trouve par exemple dans tout projet de développement logiciel les 25 granules suivants: É plan de développement É modèle d'exigence É modèle de conception É code É scénario et résultats de tests É manuels d'utilisation É notes et comptes rendus divers É messages électroniques 2. La spécificité des formats Chaque granule est stocké de manière dépendante du logiciel de mise en oeuvre de l'activité correspondante. Par exemple: É le modèle de conception est manipulé avec un éditeur de modèle, qui les stocke dans son format propre; É les notes et compte rendus sont rédigés à l'aide d'un éditeur de texte, qui les stocke dans son format propre; É les messages électroniques sont manipulés avec un logiciel de 10 messagerie, qui les stocke également dans son format propre. 3. La composition La dernière particularité des granules du développement logiciel est leur granularité et leur composition souvent arborescente. Si l'on reprend l'exemple du modèle de conception, on peut considérer que sont des granules, entre autres: É le modèle complet, É un diagramme spécifique d'un modèle, É un élément spécifique d'un diagramme tel qu'une classe. Les granules qui sont du niveau de composition le plus fin n'ont en général pas de représentation physique autonome: on ne peut y associer un fichier physique de stockage. Par exemple, une classe peut être stockée sous la forme d'une série d'enregistrements dans une base de données. L'état de la technique consiste à conférer à chaque outil une manière différente pour adresser ses granules. On a donc ainsi un schéma particulier d'adressage pour l'outil A, un autre pour l'outil B, et encore un autre pour l'outil C. Ceci entraîne une complexification des mécanismes d'échange entre outils, puisque par exemple la réalisation d'une passerelle entre A et B ne peut bénéficier d'une passerelle déjà existante entre A et C, la manière d'adresser les granules étant différente. La présente invention a pour objet un procédé d'adressage de n'importe quel granule lors de l'accès à des données logicielles hétérogènes, qui soit universel, en particulier pour respecter les trois caractéristiques des granules exposées ci-dessus. Le procédé conforme à l'invention est caractérisé en ce que l'on définit une grammaire générique d'identification des granules et qu'on applique cette grammaire dans les requêtes échangées entre outils logiciels. Dans la présente demande, on entend par outils logiciels des programmes informatiques aussi divers que les traitements de textes, les bases de données, les modeleurs UML et autres outils d'ingénierie. La présente invention sera mieux comprise à la lecture détaillée d'un mode de mise en oeuvre, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel: - Les figures 1 et 2, déjà décrites ci-dessus, sont des diagrammes servant à expliquer les procédés de l'art antérieur, et Les figures 3 et 4 sont reprises dudit brevet français 2 838 902, représentent respectivement un diagramme exposant l'étape d'identification de granules décrite dans ce brevet, et un bloc-diagramme d'une architecture à deux outils mettant en oeuvre aussi bien le procédé dudit brevet français que celui de la présente invention. Pour pouvoir créer un moyen universel d'accès aux données d'un outil, le procédé décrit dans le brevet français 2 838 902 comporte une première étape de définition d'une grammaire formelle des granules ( Artifacts en anglais, ou objets élémentaires) gérés par un outil. Par exemple, comme schématisé en figure 3, les granules gérés par un outil 1 de modélisation UML sont, dans l'ordre décroissant de taille, les projets 2 (projets individuels, produits) qui peuvent contenir chacun des types de diagrammes 3 (type séquences, type classes,...), qui peuvent eux-mêmes contenir des classes 4 (classes élémentaires, relations entre classes, ... ), qui, à leur tour, peuvent contenir des attributs 5 (caractéristiques physiques, ...). Cette grammaire permet de savoir à quel niveau de granularité 2 à 5 se trouvent les données requises par l'outil appelant et de définir sans ambiguïté les granules dans le contexte de l'outil. On a représenté en figure 4 (la même que dans ledit brevet français) un exemple d'implémentation d'adaptateur sur deux outils 6, 7 communiquant par l'intermédiaire d'un bus 8 de réseau informatique. La mémoire 6A de l'outil 6 stocke ses données sous un format propriétaire F. L'outil 6 comporte une API 9, et on lui connecte un adaptateur 10. Cet adaptateur 10 peut ne comporter qu'une partie serveur S si l'outil 6 n'est pas prévu pour être un outil appelant, mais dans la majorité des cas, l'adaptateur comportera avantageusement une partie serveur S et une partie client C. De même, l'outil appelant 7 comporte une API 11 et un adaptateur 12 constitué d'une partie client S, et, le cas échéant, d'une partie serveur S. Pour obtenir des granules de données détenus par l'outil 6, le client de l'adaptateur 12 de l'outil 7 adresse une requête 13 à l'outil 6 par l'intermédiaire du bus 8. Cette requête 13 est au format standard HTTP. Par le bus 8, la requête parvient (14) à la partie serveur de l'adaptateur 10, qui commande à l'outil 6 de sélectionner dans sa mémoire 6A le granule de données au niveau requis et de produire un fichier d'export XML 15A. Un acquittement 15 est transmis par l'adaptateur 10 vers le bus 8. Après avoir transité sur le bus 8, l'acquittement parvient (16) à l'adaptateur 12, qui l'interprète. Si nécessaire l'adaptateur 12 fabrique une copie locale du fichier XML par FTP. Il demande alors à l'outil 7 de transformer le fichier XML, par exemple, en code Cou Ada (17). Le procédé de l'invention permet d'adresser tout granule dans l'ensemble des données d'un projet logiciel, et il consiste à utiliser au moins les quatre premiers des cinq paramètres listés dans le premier tableau cidessous. Dans l'exemple N 1 ci-dessous, le granule est la feuille 25 "Résultats2003" d'un classeur Excel "MesDonnées.xls". Dans l'exemple N 2 ci-dessous, le granule est le diagramme de cas d'utilisations "Scénarios" contenu dans le -paquetage "PckgSystème. PckgSsSystème" du modèle "MonModèle.rpy" manipulable à l'aide de Rhapsody V 4.0.2. Pour Rhapsody, ce diagramme possède 3o l'identifiant interne "Azdftg345fdES4". Paramètre Notes Nom de l'outil Nom de l'outil sachant manipuler le granule, et comprenant, le cas échéant, son numéro de version Nom du projet Nom de projet incluant un éventuel chemin d'accès. conteneur Les niveaux de répertoire sont systématiquement spécifiés à l'aide de " " afin de s'abstraire des différences syntaxiques entre les différents systèmes d'exploitation. Type du granule Nature du granule. Le projet constitue un granule qui peut se décomposer en granules de niveau inférieur. Nom du granule Nom du granule tel qu'il est vu par un utilisateur. Le granule de niveau le plus haut peut être le projet conteneur. Identifiant interne du Identifiant interne éventuellement utilisé par l'outil granule manipulateur. Il doit s'agir d'un identifiant unique pour le projet considéré. Ce paramètre est optionnel, mais est généralement requis pour les outils reposant sur une base de données. Exemples: Paramètre Exemple N 1 Exemple N 2 Nom de l'outil "Excel 97" (tableur) "Rhapsody"4.0.2. (modeleur UML) Nom du projet "LeCheminDuFichier\MesDon "MonChemin\MonM conteneur nées.xls" odèle.rpy" Type du granule "Feuille" "Cas d'utilisations" Nom du granule "Résultats2003" "PckgSystème.Pck gSsSystème.Scéna rios" Identifiant interne du Non applicable "Azdftg345fdES4" granule Selon un mode de réalisation de l'invention, on décrit en langage XML la structure de données nécessaires à l'adressage d'un granule. Selon cette notation, la structure d'adressage universel est la suivante (il s'agit de la partie de désignation d'une requête, à savoir la requête 13, puis 14, comme représenté en figure 4) : Cette structure peut ensuite être manipulée par tout programme désirant adresser un granule particulier. Le procédé de l'invention pour l'adressage universel d'un granule 20 logiciel permet une normalisation des adressages de granules, ce qui concourt à une simplification des interfaces avec les outils logiciels. Cette simplification peut se décliner avec différentes applications. Tout d'abord, de nombreuses actions manuelles peuvent être facilement automatisées. Par exemple, il est possible de naviguer entre outils, c'est-à-dire, à partir de l'adressage d'un granule externe dans un outil, de lancer automatiquement un autre outil avec positionnement sur le granule adressé. Il est également possible à un outil de demander à un autre outil d'exporter un de ses granules, par exemple sous forme XML, puis de récupérer cet export afin de l'utiliser. On peut bâtir au-dessus de ce mécanisme un système de production automatisée de documents à partir de granules provenant de différents outils. Une deuxième application de l'adressage universel est la simplification de l'établissement de la traçabilité entre granules. La preuve de cette traçabilité entre granules, par exemple entre exigences et tests, est traditionnellement requise par les normes applicables au développement logiciel. Une troisième application de l'adressage universel est la simplification de la réalisation d'un moteur de recherche dans le contexte des données d'un projet. Très similaire dans son principe à un moteur de recherche sur Internet, il s'en différencie par le type d'objet indexé, puisqu'il s'agit uniquement de données d'ingénierie. L'utilisation de références normalisées aux granules permet un référencement plus simple par le moteur de recherche. REVENDICATIONS 1. Procédé d'adressage universel de granules logiciels pour la simplification de l'accès à des données hétérogènes gérées par des outils logiciels, caractérisé en ce que l'on définit une grammaire générique d'identification des granules et qu'on applique cette grammaire dans les requêtes échangées entre outils logiciels. 2. Procédé selon la revendication 1, caractérisé en ce que la grammaire générique comporte au moins les quatres paramètres suivants: nom de l'outil , nom du projet conteneur . type de granule et nom de granule . 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la grammaire générique comporte en outre le paramètre identifiant interne du granule . 4. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'à partir de l'adressage d'un granule dans un outil, on lance automatiquement un autre outil avec positionnement sur le granule adressé. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'on fait demander par un outil à un autre d'exporter un de ses granules, 20 puis qu'on lui fait récupérer cet export pour qu'il l'utilise. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il est mis en oeuvre dans un système de production automatisée de documents à partir de granules provenant de différents outils. 7. Procédé selon l'une des revendications précédentes, 25 caractérisé en ce qu'il est mis en oeuvre pour établir la traçabilité entre granules. 8. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il est mis en oeuvre pour la réalisation d'un moteur de recherche.