MÉMOIRE DE STAGE DE MASTER SPÉCIALITÉ : Recherche en Informatique Mention : Informatique, Mathématiques, Statistiques

Transcription

1 ACADÉMIE DE MONTPELLIER UNIVERSITÉ MONTPELLIER II SCIENCE ET TECHNIQUES DU LANGUEDOC MÉMOIRE DE STAGE DE MASTER SPÉCIALITÉ : Recherche en Informatique Mention : Informatique, Mathématiques, Statistiques Organisation / Sélection dans les bibliothèques de composants Trading de composants KHALED OUAFI Date de soutenance: Juillet 2006 Effectué au sein du Laboratoire de Génie Informatique et d Ingénierie de Production de l Ecole des Mines d Alès Sous la direction de CHRISTELLE URTADO et SYLVAIN VAUTTIER

2 Remerciements Je tiens tout d abord à exprimer toute ma gratitude à Monsieur Yannick Vimont, Directeur du Laboratoire de Génie Informatique et d Ingénierie de Production de l Ecole des Mines d Alès, pour m avoir permis de réaliser mon stage de Master dans son laboratoire. Je remercie également Monsieur Roland Ducournau, Responsable de la Spécialité Recherche en Informatique du Master mention IMS à l université Montpellier II, de m avoir accueilli au sein du département Informatique. Je tiens à remercier mes tuteurs Madame Christelle Urtado et Monsieur Sylvain Vauttier, pour leur encadrement, leur présence, leurs connaissances, ainsi que l accueil qu ils m ont fait au sein de leur équipe de recherche. En fait c est grâce à leur support, leurs remarques, leurs efforts, leurs conseils, leurs contrôles, leur direction, leur patience, leur bonté et toutes les informations qu ils m ont fournies que ce mémoire a pu voir le jour sous cette forme. Je remercie également Madame Sylvie Cruvellier la secrétaire du laboratoire, et Madame Francoise Armand la responsable de la bibliothèque. J exprime également ma reconnaissance et mes remerciements au thésard Nicolas Desnos, qui m a accueilli et aidé avec beaucoup de patience tout au long de mon stage. A mes amis profonde reconnaissance. Enfin, à mes parents et à toute la famille un grand merci pour leur soutien et plus particulièrement à ma sœur Khalida de Strasbourg à qui je souhaite pleine réussite à sa thèse de doctorat. 1

3 Table de Matières I. Introduction générale Contexte et problématique Objectifs Plan du mémoire...9 Chapitre II. Les approches à composants Introduction Composants Les spécifications d un composant Les interfaces de composant Niveaux sémantique et protocole Niveau port Modèle de composants Le modèle de composant Fractal et son ADL Notre modèle de composant Conclusion...17 Chapitre III. Les approches de Recherche de Composants Introduction Systèmes de recherche de composants Classification par scénario d utilisation Classification par famille Les techniques de recherche de composants Les techniques classiques de recherche d information Les techniques de classification externe Les techniques de classification structurelle Les techniques de recherche comportementale Techniques de recherche par navigation Conclusion...27 Chapitre IV. Trading et composants Introduction Service dynamique de localisation Service de nom Service d annuaire Service de trading Les Spécifications requises pour un service de trading de composant Le Trading actuel Trading de composant Architecture du service de trading de composant Une étude de la fonction de trading du modèle de RM ODP La fonction de trading d'odp Exigences pour les traders de composants

4 6. Conclusion...45 Chapitre V. Un service de trading pour composants à partir de leurs ports Introduction Services et types de service Un Trader pour composants décrits par leurs ports Exportation des services Importation des services Le processus de trading Choix du type de SGBD : XML ou relationnel Conclusion...56 VI. Conclusion et perspectives...57 Annexe A: Extension du schéma de lʹadl Fractal...60 Annexe B : Schéma du document XML de la requête d importation...62 Annexe C : Déroulement d un exemple d application...63 Annexe D : Feuille de style XSL pour le schéma XML de composants VII. Bibliographie

5 Liste des figures Figure 1.1 : Deux aspects de la réutilisation [KHA 05]....5 Figure 1.2 : Cycle de vie des composants réutilisables....6 Figure 1.3 : Différentes facettes de la problématique de la recherche de composants...7 Figure 2.2 : Une station service avec des composants Fractal...15 Figure 2.3 : L architecture logicielle de la station service avec l ADL Fractal Figure 2.4 : Un méta modèle de composants qui inclut les ports primitifs et composites [DES 06]...16 Figure 3.1 : Classification des systèmes de recherche de composants [KHA 05]...20 Figure 3.2 : Architecture classique dʹun système de recherche d information ad hoc appliqué aux composants...21 Figure 3.3 : Architecture classique dʹun système de recherche d information routage appliqué aux composants...21 Figure 4.1 : Niveau dʹabstraction pour la décomposition du système d information dʹentreprise [TER 99a]...30 Figure 4.2 : Utilisation du service trading des composants pour le développement des SI [TER 99a]...30 Figure 4.3 : Architecture du service trading de composant [TER 99b]...34 Figure 4.4 : Les rôles du trading dʹodp...37 Figure 4.5 : Lʹordre des taches dans le rôle dʹimportateur du trader dʹodp [IRI 01]...41 Figure 4.6 : Propagation dʹune requête dans une fédération de trader dʹodp [IRI 01]...42 Figure 5.1 : Différents formats de l objectif fonctionnel

6 I. Introduction générale 1. Contexte et problématique Le travail présenté dans ce stage s inscrit dans le domaine de la réutilisation de composants et plus précisément dans la recherche et la classification des composants réutilisables. Faciliter et imposer la réutilisation dans l ensemble du processus de développement des systèmes d information (SI) nécessite un cadre technique, méthodologique et organisationnel. Pour ce faire, deux types de processus complémentaires doivent cohabiter comme le montre la figure 1.1 : Figure 1.1 : Deux aspects de la réutilisation [KHA 05]. Développement de composants réutilisables («Design for reuse») : une ingénierie de composants est nécessaire afin de créer, d enrichir puis de maintenir un référentiel de composants réutilisables. Le développement dʹun système de réutilisation doit mettre en œuvre les fonctionnalités d identification, de spécification, de développement, de validation et d organisation des composants. Ce développement suit un processus coopératif et itératif demandant la participation et la mise en accord d experts du domaine. Développement d applications à base de composants («Design by reuse») : un 5

7 tel développement nécessite de nouveaux environnements intégrant de manière systématique la réutilisation de composants. Ces nouveaux environnements doivent intégrer des fonctionnalités de sélection, d adaptation et d intégration de composants pour composer progressivement le système final. La figure 1.2 montre un cycle de vie des composants réutilisables et les différents métiers à travers un exemple d organisation d une équipe de développement de SI adoptant une approche de développement par réutilisation de composants. L exemple met en évidence le rôle central que jouent les bibliothèques de composants dans une telle organisation. Il est donc capital de bien réussir l automatisation de la gestion des bibliothèques de composants pour garantir l aboutissement et l efficacité du projet de réutilisation. Figure 1.2 : Cycle de vie des composants réutilisables. Face à l émergence de collections de composants réutilisables de différents types (conceptuels, logiciels, etc.), certains environnements professionnels de développement d applications ont évolué vers une gestion sommaire de composants. Or, si ces outils permettent effectivement de gérer des bibliothèques de composants, ils n en facilitent pas pour autant leur sélection et leur utilisation par une recherche ou une navigation adaptée. Les bibliothèques de composants sont des éléments clés dans les environnements de développement à base de composants et de réutilisation de 6

8 composants (cf. figure 1.2), mais leur efficacité est optimale lorsque les développeurs et les concepteurs disposent de bibliothèques riches en composants testés et validés, ce qui augmente la fiabilité et diminue le temps de développement des systèmes d information résultants. Malheureusement, mettre simplement à disposition des développeurs des bibliothèques de composants de taille importante n augmente pas forcément la productivité. Le concepteur a besoin de techniques performantes de recherche et de classification de composants. La figure 1.3 situe le domaine de la recherche de composants par rapport aux domaines de l ingénierie des SI, de l ingénierie des composants et de la recherche d information. Figure 1.3 : Différentes facettes de la problématique de la recherche de composants. Telle est la problématique de notre sujet qui situe l importance, la place et l intérêt de notre recherche. 2. Objectifs Lors du processus de développement d une application, le concepteur produit les composants et documente (méta données) leur comportement. Ces méta données sont généralement décrites sous la forme de protocoles qui décrivent les séquences d opérations valides. Un architecte construit une application en sélectionnant des 7

9 composants puis en les assemblant. La cohérence d un assemblage peut être contrôlée à deux niveaux : un niveau syntaxique, dans lequel les types des interfaces connectées sont comparés (interface matching), et un niveau sémantique, dans lequel ce sont les protocoles qui sont comparés. Le processus appropriés de recherche et de choix des composants sont devenus les pierres angulaires de chaque développement efficace à base de composants. Cependant, ces processus font face actuellement à des limitations sérieuses, généralement dues à trois raisons principales. Dʹabord, lʹinformation disponible sur les composants nʹest pas assez expressive pour leur choix efficace. En second lieu, la recherche et les critères d évaluations offertes par les traders courants sont habituellement trop simples pour être utiles en pratique. Enfin, les méthodologies courantes de l ingénierie à base de composants n exploitent pas efficacement le trading pour la recherche et la localisation des composants offrant les services exigés. Dʹabord, une des questions clés dans le développement orienté composant est lʹutilisation dʹune documentation de composants plus complète, plus concise et non ambiguë (c. à d. spécifications). Dans le cas des composants logiciels, leur nature de boîte noire gène la compréhension de leur comportement interne. En outre, seulement les propriétés fonctionnelles sont habituellement prises en considération, alors quʹune autre information cruciale au choix de composant est absente, comme les protocoles ou lʹinformation sémantique [VAL 00], les ports [DES 06] ou les conditions fonctionnelles supplémentaires [ALV 01, CHU 99]. Les fournisseurs de composant logiciel sont également sans aide, fournissant des informations rares et non structurées au sujet des composants [BER 03]. En second lieu, les processus de recherche et d appariement de composant (dans la théorie) sont délégués aux traders, mais le problème est que les traders existants ne fournissent pas toute les fonctionnalités exigées pour un trading sémantique de composants efficace, comme discuté dans [TER 99a]. Enfin, les traders ne sont pas entièrement intégrés dans les méthodologies courantes pour réaliser un développement à base de composants efficace, par conséquent ils manquent plusieurs des avantages potentiels fournis par les traders tels que la découverte de lʹinformation ou le choix partiellement automatisé des composants candidats. Dans ce mémoire, nous présentons un service de trading qui essaye dʹadresser la plupart de leurs imperfections courantes. Une extension dʹinformation utilisée pour décrire les services de composants est également présentée, où non seulement les 8

10 aspects syntaxiques des interfaces sont pris en considération, mais également l exigence syntaxique de collaborations entre interfaces contenue dans les ports, une template pour décrire les requêtes de services est définie. Avec tout cela, il est possible dʹaméliorer les deux services des processus ʹexportationʹ et ʹimportationʹ, et de concevoir et développer les traders améliorés qui se servent des avantages de l information de port pour localiser et rechercher les composants. Il y a plusieurs travaux qui adressent lʹinteropérabilité des composants, aux trois niveaux : niveau signature [OMG 99, ZAR 95], niveau protocole [CAN 00, YEL 97], et niveau sémantique [ROS 01, DHA 96]. Notre approche essaye d étendre cette compatibilité au niveau port [DES 06]. Les notions de ports primitifs et composites constituent un enrichissement des modèles de composants usuels. Nous les proposons comme concepts de granularité adaptée pour assister l architecte lors de la sélection des composants à connecter pour construire une architecture. Plus riches que les simples interfaces, ils véhiculent de l information sur les collaborations que les composants sont susceptibles d établir entre eux. Plus synthétiques et lisibles que les protocoles, ils contiennent tout de même une information sur les dépendances entre interfaces, pertinente pour assister le choix des composants. Les ports primitifs et les ports composites représentent ainsi une abstraction des collaborations potentielles et des dépendances. Tels sont les objectifs de notre travail. 3. Plan du mémoire Ce mémoire est organisé en 6 chapitres. Le chapitre II présente les approches à composants. Cette étude permet l identification des différents niveaux de compatibilité susceptibles d être utilisés lors du processus de développement de systèmes d information. Le chapitre III présente un état de l art sur les techniques de recherche de composants (TRC). Après la présentation d une classification des différentes techniques, nous en présentons des exemples pour chacune des catégories identifiées. Enfin, nous définissons des critères d évaluation des différentes techniques qui nous permettent de les comparer Le chapitre IV présente la relation entre Trading et composants, puis analyse la fonction de trading du standard ODP et ses limitations pour les composants. De 9

11 même, nous proposons une liste d exigences quʹun trader de composants doit accomplir. Ces exigences ont crée les bases pour une implémentation dʹun trader pour des composants décrits par leurs ports. Le chapitre V présente un nouveau service de trading pour composants à partir de leurs ports. Dans un dernier chapitre nous résumons les apports de ce travail et les perspectives envisagées. Des annexes complètent ce document pour en illustrer certaines parties un peu abstraites. 10

12 Chapitre II. Les approches à composants 1. Introduction L approche à base de composants est depuis une dizaine d années considérée comme un nouveau paradigme de développement des systèmes d information [BAR 02]. Les activités de programmation ont été les premières concernées par ce nouveau paradigme. Ce chapitre présente les approches à base de composants. Nous présentons dans les sections 1 et 2 respectivement les notions de composant et leurs spécifications. La section 3 définie un modèle de composant, Ensuite, nous décrirons le modèle de composant Fractal et son ADL. Enfin nous présentons notre modèle de composant comportant les ports primitifs et composites. 2. Composants A l heure actuelle, il n existe pas de normalisation de la notion de composant. Il y a un certain nombre de définitions différentes avec des différences subtiles. Une définition précise est importante afin de déterminer lʹensemble de caractéristiques qui sont significatives pour la description du composant et plus tard pour le trading de composant. La définition suivante donnée par [SZY 98] semble être claire et concise : «un composant logiciel peut être vu comme une unité de composition avec des interfaces fournies et requises contractuellement spécifiées. Cette unité est déployable et toutes ses dépendances externes sont explicites.» 3. Les spécifications d un composant Dans cette section, nous décrivons les caractéristiques d un composant logiciel c.à.d, les interfaces et lʹinformation sémantique, telle que les pré/post conditions, les protocoles et les ports Les interfaces de composant Les composants sont généralement décrits par un ensemble d interfaces qui définissent ce que le composant est capable de fournir et ce que le composant doit requérir Les interfaces peuvent être décrites en utilisant plusieurs notations différentes, selon lʹinformation que nous voulons inclure, et le niveau du détail de spécification. Par exemple, les interfaces de CORBA comprennent les attributs, les types, et les méthodes 11

13 publics dʹobjet. COM suit une approche semblable, mais les composants peuvent avoir plusieurs interfaces, chacune décrit la signature des opérations fournies. Le modèle de composants de CORBA (CCM) stipule également que les interfaces de composants peuvent décrire non seulement les services quʹil fournit, mais également les services qu il exige dʹautres composants pendant son exécution. Cependant, ce genre dʹinformation dʹinterface, également connu sous le nom dʹinformation au niveau de signature ou niveau syntactique, sʹest avéré insuffisant pour le développement d applications [YEL 97, ZAR 95]. 3.2 Niveaux sémantique et protocole Dans les signatures, le niveau sémantique traite la signification des opérationsc.à.d, le comportement [LEA 00] cependant beaucoup plus puissant que les descriptions de signatures seulement. La sémantique comportementale des composants présentent des difficultés sérieuses quand elle est appliquée à de grandes applications : la complexité informatique de prouver les propriétés comportementales des composants et des applications gêne son utilité pratique. Le niveau syntaxique traite les signatures, tandis que la sémantique couvre les aspects «comportementaux» de compatibilité entre composants. En outre, [KON 95] se rapporte aussi à eux comme niveaux statique et dynamique, et [BAS 00] parlent des composants «plug and play», en se rapportant à ces deux niveaux. Le niveau protocole traite juste les protocoles dʹaccès aux services des composants, c.à.d, lʹordre dans lesquels les composants sʹattendent à ce que leurs méthodes soient appelées, et lʹordre dans lequel elles appellent dʹautres méthodes [VAL 00]. Ce niveau, défini par [YEL 97], fournit des contrôles de compatibilité plus puissants que ceux offerts par le niveau de signature usuel. Naturellement, il ne couvre pas tous les aspects sémantiques des composants, mais il nʹest pas mal par rapport aux contrôles sémantiques lourds. C est pourquoi, nous pensons qu il peut être intéressant de définir un niveau de compatibilité intermédiaire entre le niveau syntaxique classiquement mis en oeuvre grâce aux interfaces et la comparaison des protocoles. 3.3 Niveau port Un port [OMG b, ALD 02, HAC 04, BOE 02, PRO03] est une méta information qui documente le comportement d un composant : il décrit le rôle que peut jouer ce 12

14 composant dans une collaboration. Les ports bidirectionnels regroupent les interfaces fournies et requises qui sont utilisées conjointement au sein d une même collaboration. Les ports primitifs composés uniquement d interfaces ne sont pas suffisamment expressifs dans le cas de collaborations complexes. Dans [DES 06] (cf figure 2.4) une proposition d enrichir la description de composants de ports composites pour permettre de représenter tous les types de collaborations. 4. Modèle de composants Un modèle de composants consiste en un ensemble de conventions à respecter dans la construction et l utilisation des composants. L objectif de ces conventions est de permettre de définir et de gérer d une manière uniforme les composants. Elles couvrent toutes les phases du cycle de vie d un système d information à base de composants : la conception, l implantation, l assemblage, le déploiement et l exécution. Concrètement, un modèle de composants décrit certains aspects des composants comme la définition de composants à partir d objets (classes, modules, etc.), les relations entre les composants, les propriétés fonctionnelles et non fonctionnelles de chaque composant, les techniques d assemblage des composants, le déploiement et l exécution d un système d information à base de composants, etc. Dans la pratique, un modèle de composants donné est spécifique à une phase du cycle de vie du composant et du système d information. On trouve ainsi des modèles de composants pour la phase de conception (patrons de conception), et d autres pour les phases d implantation et de déploiement (EJB, CCM, etc.). 5. Le modèle de composant Fractal et son ADL Il existe de nombreuses plates formes à composants comme EJB,.NET ou CCM qui reçoivent de plus en plus d intérêt aussi bien au niveau académique qu industriel. Cependant ces modèles sont principalement dédiés à des composants de gros grain pour des applications de type système d information. Les classes qui implémentent ces composants, suivent des règles de programmation, sont pointées par des descripteurs XML et doivent être exécutées par des serveurs d applications. Elles ne peuvent pas être manipulées aussi facilement que des objets d une machine virtuelle. De plus, les services techniques de ces plates formes sont figés et ne peuvent pas être modifiés, retirés ou ajoutés de façon standard en fonction des besoins. Ainsi, en dépit de cette large adoption de la communauté, demeure le besoin d un modèle de composant léger, proche des concepts d un langage de programmation et ne réclamant pas une mécanique lourde comme les modèles précédemment cités. Le 13

15 modèle de composant Fractal [BRU 04] répond à ces besoins. De plus, un ADL à base de descripteurs XML fait partie des sous projets liés à Fractal. Le modèle de composant Fractal permet la définition, la configuration, et la reconfiguration dynamique de composants et offre une séparation claire entre les besoins fonctionnels et non fonctionnels d une application. Construit comme un modèle de haut niveau, son objectif est de fournir une grande modularité et des possibilités d extension étendues. Le modèle est récursif : un composant est de type primitif ou composite. Dans ce dernier cas, le composant correspond à un assemblage d autres composants primitifs ou composites. Un composant peut également être partagé entre différents composites. Les interfaces jouent un rôle central dans Fractal. Il en existe deux catégories : les interfaces fonctionnelles et celles de contrôle. Les interfaces fonctionnelles sont les points d accès externes d un composant. Fractal offre des interfaces client et serveur. Une interface serveur reçoit des opérations d invocation et une interface cliente en émet. Ainsi une liaison Fractal représente une connexion entre deux composants (liaison primitive). Des liaisons de type multiples (liaisons composites) sont autorisées. Le modèle est fortement typé. De ce fait le type d une interface serveur doit être un sous type de l interface client à laquelle elle est reliée. Comme leur nom l indique, les interfaces de contrôle permettent un certain niveau de contrôle du composant auquel elles sont associées. Ces interfaces ont à charge les besoins non fonctionnels du composant, par exemple la gestion du cycle de vie ou des liaisons à d autres composants. Programmer avec Fractal Cette section illustre par un exemple les concepts du modèle de composant Fractal. La figure 2.2 représente le modèle d une station service. Chaque rectangle correspond à un composant. Les clients utilisent un pistolet pour remplir leur réservoir et payent leur carburant à une caisse connectée à une banque. Chacun de ces composants est un composant primitif Fractal. Nous avons représenté deux composants composites : le premier pour la station, le second pour le système complet. Les composites correspondent à un assemblage de composants primitifs ou composites. Les T attachés aux composants représentent les interfaces fonctionnelles (les interfaces de contrôle ne sont pas représentées sur la figure). Les flèches caractérisent les liaisons entre composants et sont orientées : d une interface cliente vers une interface serveur. Fractal met à disposition une API permettant de créer, introspecter et gérer les 14

16 composants, leurs interfaces et leurs liaisons. Par exemple un composant peut être démarré et arrêté et des liaisons peuvent être créées dynamiquement. Figure 2.2 : Une station service avec des composants Fractal. La définition de l architecture d une application s effectue grâce à un descripteur XML de l ADL Fractal. La figure 2.3 présente un extrait de cette définition dans notre exemple de la station service. Figure 2.3 : L architecture logicielle de la station service avec l ADL Fractal. 15

17 6. Notre modèle de composant Cette sous section vise à présenter comment les ports primitifs et composés sont intégré à un modèle de composant : Elle décrit ainsi un méta modèle de composant. Ce méta modèle [DES 06], comme présenté dans la figure 2.4, est inspiré par le modèle de composants Fractal [BRU 04]. Un composant est récursivement défini (il est hiérarchique). Il est composé dʹune membrane et dʹune architecture, elle même composée de composants. La membrane est décrite par lʹensemble dʹinterfaces représentant les services des composants. La membrane constitue un méta niveau qui permet lʹintrospection et lʹintersession sur le composant. Un port primitif est une représentation abstraite des contributions et des besoins dʹun composant dans une collaboration. Il contient les interfaces requises et fournies. Un port composé est la représentation abstraite dans une collaboration complexe en laquelle des sous collaborations peuvent être distinguées. Ces derniers sont considérés assez indépendant à être représentés en tant que ports séparés qui font partie du port composite. Par ce moyen, la contrainte dʹêtre connecté à un seul composant est relaxée. Figure 2.4 : Un méta modèle de composants qui inclut les ports primitifs et composites [DES 06]. 16

18 7. Conclusion Ce chapitre a présenté les approches à composants en faisant ressortir leurs spécifications. Aussi, Le modèle de composant Fractal et son ADL sont décrits. Puis notre modèle de composant comportant les ports primitifs et composites est présenté. Différents types de composants susceptibles d être utilisés lors du processus de développement de systèmes d information existent. Pendant chacune des phases de développement, Les acteurs d une équipe de développement de systèmes d information sélectionnent et réutilisent des composants qui répondent partiellement ou totalement à leurs besoins. Il est évident que la recherche d un composant varie énormément selon son niveau d abstraction et son modèle de composants. Il y a plusieurs travaux qui adressent lʹinteropérabilité des composants, aux trois niveaux : niveau signature [OMG 99, ZAR 95], niveau protocole [CAN 00, YEL 97], et niveau sémantique [ROS 01, DHA 96]. Notre approche essaye d étendre cette compatibilité au niveau port [DES 06]. 17

19 Chapitre III. Les approches de Recherche de Composants 1. Introduction La recherche dʹinformation (RI) occupe une place importante dans les systèmes dʹinformation. En effet, sʹil est important de savoir modéliser lʹinformation, il est également nécessaire de pouvoir y accéder facilement. Lʹaugmentation du nombre de documents au niveau des entreprises et des institutions ainsi que l avènement des documents électroniques, des documents multimédias et de l Internet nécessite la mise en place de systèmes sophistiqués de recherche dʹinformation. De la même manière, la recherche de composants est fondamentale pour l ingénierie des systèmes à base de composants. L augmentation du nombre de modèles de composants ainsi que l avènement des composants sur étagère (Components Off The Shell) nécessite la mise en place de systèmes sophistiqués de recherche de composants Ce chapitre présente un état de l art des différentes techniques permettant la recherche de composants. Il présente tout d abord une introduction au domaine de la recherche de composants. La deuxième section est consacrée à une identification et classification des différents types de systèmes de recherche de composants. Enfin, La troisième section présente les différentes techniques de recherche de composants que nous avons identifiées. La recherche d information (RI) est un domaine relativement ancien (plus de 30 ans) qui a connu ces dernières années une évolution rapide surtout après l avènement de l Internet et des documents multimédias. Cependant les principes de base des techniques de RI ont peu évolué ; seuls les corpus documentaires ont changé. Un composant pouvant être assimilé à un document électronique. Nous examinons dans un premier lieu s il est possible d appliquer les techniques de recherche d information sur une collection de composants. Avant d aller plus loin dans la présentation du domaine de la recherche d information en général et du domaine de la recherche de composants en particulier, définissons le vocabulaire que nous utilisons dans la suite de ce mémoire. Composants et artefacts Le chapitre 2 définit un composant comme une unité réutilisable de conception (de n importe quel niveau d abstraction) décrite selon un modèle de composants. 18

20 Dans la littérature, on trouve aussi le concept d artefact (en anglais asset ou artefact). La notion d artefact est encore plus générale et n inclut pas seulement la notion de composant, mais elle peut s étendre à la notion de procédure, module, classe, modèle, documentation, spécification, donnée de test, etc. Dans la suite de cet état de l art, nous ne distinguons pas la notion de composant de la notion d artefact car nous considérons qu un composant peut être assimilé à un ensemble d artefacts. Rechercher les artefacts revient donc à rechercher les composants. Nous considérons les artefacts et les composants comme étant des documents électroniques. Lors de la présentation des techniques de RI appliquées aux composants, nous parlons uniquement de composants et de bases de composants. Base de composants Une base de composants est une collection de composants maintenue selon une organisation permettant la recherche et la sélection des composants. Requête Une requête est une expression de termes qui décrivent les besoins en information de l utilisateur. Le concept de terme est souvent associé à une expression textuelle sous la forme d un mot. 2. Systèmes de recherche de composants Il existe fondamentalement deux approches de systèmes de recherche de composants [KHA 05] : l approche par navigation et l approche par requêtes (cf. figure 3.1). Dans l approche par navigation, le système de recherche d information exploite les liens sémantiques qui peuvent exister entre les composants pour faire de la navigation. Dans l approche par requêtes, le principe de base consiste à faire correspondre une requête à une collection de composants et à retourner les composants pertinents à l utilisateur. Le succès de ce type de systèmes dépend en partie de la qualité et de la quantité d informations associées à la requête et aux composants de la base de composants. En effet avec une grande quantité d informations définissant la pertinence des composants, le système sera en mesure d employer des techniques plus avancées pour classer les composants pertinents et non pertinents. 19