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 collections de composants, ils n?en facilitent pas pour autant leur s�lection et leur utilisation par une recherche adapt�e. Les bases de composants sont des �l�ments cl�s dans les environnements de d�veloppement � base de composants et de r�utilisation de composants. L?efficacit� de tels environnements est optimale lorsque les d�veloppeurs et les concepteurs disposent de bases 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 bases 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.

Dans cet article, nous ne nous int�ressons pas aux bases de composants uniquement du point de vue recherche de composants mais nous les exploitons pour la construction d?une base de connaissances servant � la r�ing�nierie de syst�mes d?information. Nous consid�rons dans cet article le probl�me de r�ing�nierie des syst�mes d?information comme l?inverse du probl�me de la recherche de composants. En effet, les composants de la base sont transform�s en requ�tes et ils sont recherch�s dans le code ou dans le mod�le de conception du syst�me d?information sur lequel le processus de r�ing�nierie est appliqu�.

La deuxi�me section pr�sente un bref �tat de l?art des techniques structurelles de recherche de composants. La section 3 introduit le concept de sp�cification formelle en logique du premier ordre d?un diagramme de classes UML. Puis, les sections 4 et 5 pr�sentent successivement les processus de g�n�ration d?une sp�cification source et d?une sp�cification cible. La section 6 propose un m�canisme d?appariement de sp�cifications � base des m�ta-connaissances. Enfin, la section 7 d�crit un outil implantant cette technique ainsi que des exemples de son utilisation.

Il existe principalement deux types d?approches structurelles de recherche de composants�(TRC) : les TRC par appariement de signatures et les TRC par appariement de sp�cifications.

Les TRC � base de signatures exploitent les techniques d?appariement et de transformation de types pour retrouver les composants. Dans un cadre standard de d�veloppement par objets, un composant est construit par composition de classes. Une classe d�clare un ensemble de m�thodes, de types et d?attributs. Un composant peut donc �tre repr�sent� par l?ensemble des signatures des entit�s qu?il contient. Les signatures peuvent �tre bas�es sur des types simples, des types complexes voire des fonctions. ��

Dans (Ritti, 1989), Ritti propose une technique d?appariement de signatures et applique sa m�thode � une collection de composants �crits dans un langage fonctionnel. L?algorithme d?appariement (c'est-�-dire la mesure de la distance) que Ritti adopte utilise un syst�me de type polymorphique et garantit une invariance vis-�-vis de l?ordre des d�clarations dans un type. Dans (Ritti, 1992), Ritti am�liore le rappel de sa technique en relaxant la condition d?appariement sur l?isomorphisme de types.

Runciman et Toyn (Runciman et Toyn, 1989) proposent une approche similaire � celle de Ritti en utilisant des types polymorphiques pour d�finir des crit�res d?appariement de signatures dans le contexte de la programmation fonctionnelle. L?apport de cette approche consiste dans l?ind�pendance du crit�re d?appariement vis � vis du nombre d?arguments des m�thodes, ce qui am�liore le crit�re de rappel.

Deux auteurs, Zaremski et Wing, (Zarimski et Wing, 1993) (Zarimski et Wing, 1995) proposent une technique de classification et de recherche de composants bas�e sur les signatures. Deux signatures sont consid�r�es compatibles si elles sont identiques modulo un renommage et une permutation des noms et des param�tres des m�thodes. Une relaxation des crit�res d?appariement (�quivalence) permet d?am�liorer le rappel de cette approche. Les auteurs proposent deux types de relaxation�: par changement du crit�re d?appariement ou par transformation des signatures de la requ�te et des composants. Ces deux types de relaxation peuvent �tre combin�s pour produire d?autres crit�res d?appariement.

Les techniques de recherche de composants par appariement de sp�cifications tentent de retrouver les composants dont les sp�cifications correspondent (sont compatibles avec) � celle de la sp�cification requ�te. Zaremski et Wing ont �tendu leurs travaux sur les signatures pour proposer une approche par appariement de sp�cifications de composants (Zaremski et Wing, 1995a). Ils repr�sentent les requ�tes et les composants par un ensemble de paires de pr�- et post- conditions (une paire par m�thode). Ils d�finissent aussi un crit�re g�n�ral d?appariement d�fini par la formule suivante�:

En variant les relations R₁,R₂,R₃ Zaremski et Wing obtiennent une hi�rarchie de crit�res d?appariement.

Rollins et Wing (Rollins et Wing, 1991) pr�sentent une base de composants o� les composants sont sp�cifi�s en langage ??Prolog. Cette technique exploite les m�canismes d?inf�rence du langage ??Prolog pour l?appariement des sp�cifications.

Hemer et Lindsay proposent une base de modules (Hemer et Lindsay, 2001). Un module est un ensemble d?unit�s. Une unit� peut �tre une proc�dure, une classe ou une structure de donn�es. Si un d�veloppeur a besoin d?un module qui implante toutes les op�rations sur les listes cha�n�es, alors il doit sp�cifier toutes les primitives dont il a besoin sous la forme d?unit�s, puis il cherche dans la base le module qui contient ses unit�s. Hemer et Lindsay proposent trois strat�gies de recherche de modules�: ALL-match, SOME-match et ONE-match. �Le crit�re ALL-match v�rifie que toutes les unit�s de la requ�te correspondent � des unit�s distinctes du composant. Le crit�re SOME-match relaxe le crit�re ALL-match en se contentant de v�rifier qu?au moins un sous-ensemble non vide d?unit�s de la requ�te correspond � un sous-ensemble non vide d?unit�s du composant. �Le crit�re ONE-match v�rifie qu?au moins une des unit�s de la requ�te correspond � une des unit�s du composant.

Nous nous sommes int�ress�s dans cette section aux approches structurelles de recherche de composants. Les techniques par appariement de signatures sont en r�alit� un cas particulier des techniques par appariement de sp�cifications. En effet, les sp�cifications de techniques par appariement de signatures s?int�ressent uniquement aux signatures des composants. Bien que ces deux types d?approches donnent de bons r�sultats et poss�dent des fondements th�oriques solides, leur utilisation reste assez difficile et destin� � des sp�cialistes ayant de bonnes connaissances des langages de sp�cifications formelles. Nous pr�sentons dans la suite de cet article une technique structurelle de recherche de composants par appariement de sp�cifications �labor�e par notre �quipe. L?apport principal de cette technique vis-�-vis des techniques que nous avons pr�sent�es est sa transparence et sa simplicit� de mis en ?uvre. En effet, la technique propos�e est bas�e sur deux processus de g�n�ration de sp�cifications formelles en logique du premier ordre � partir de diagrammes de classes UML�; elle permet � un utilisateur d?indexer ses composants et de sp�cifier ses requ�tes avec des diagrammes de classes.

La pr�sente un exemple de diagramme de classes types pouvant documenter un syst�me d?information. La notion d?article composite a �t� mod�lis�e en imitant la solution du patron Composite (Gamma et al., 1995). Si nous voulons faire de la r�ing�nierie de ce syst�me d?information pour d�tecter les composants qui ont servi � sa construction, le formalisme graphique semi formel d?UML n?est pas bien adapt� � cette t�che. Notre but est de passer de la repr�sentation graphique, semi formelle � une repr�sentation formelle facilitant les t�ches de comparaison et d?appariement de diagrammes de classes. La logique du premier ordre offre l?avantage de permettre la description de la structure d?un diagramme de classes sous la forme de formules logiques. Le calcul des pr�dicats en tant que th�orie du premier ordre d�finit des axiomes et des r�gles d?inf�rence qui permettent de prouver qu?une formule est une cons�quence logique d?une autre formule. Nous utilisons donc cette technique pour d�tecter la structure d?un composant (d�fini par un diagramme de classes cible) dans un syst�me d?information (d�fini par un diagramme de classes source). Cela est le cas si la formule logique sp�cifiant le composant est une cons�quence logique de la formule sp�cifiant le syst�me d?information.

Dans l?exemple propos� de diagramme de classes (figure 1), la sp�cification cible serait la sp�cification de la solution du patron Composite et la sp�cification source serait la sp�cification de tout le diagramme de classes du syst�me d?information. Un prouveur de th�or�mes tentera de prouver que la sp�cification cible est une cons�quence logique de la sp�cification source. Ainsi, il d�tectera la structure du patron composite dans le diagramme de classes de la figure 1. La figure 1 pr�sente les principaux concepts qu?un diagramme de classes UML peut contenir�: classe, g�n�ralisation, association, r�alise, op�ration, attribut, agr�gation, composition, r�le, multiplicit�, navigabilit�, visibilit�, st�r�otype, etc.

La sp�cification qui suit d�crit par exemple la relation de g�n�ralisation qui existe entre la classe Client et la classe Client_individu de la figure 1. Nous utilisons le pr�dicat entit�() pour d�clarer trois �l�ments de mod�lisation⁽¹⁾. Puis, nous utilisons le pr�dicat classe() pour d�clarer les entit�s id1 et id2 comme �tant des classes⁽²⁾. Ensuite, nous utilisons le pr�dicat g�n�ralisation()⁽³⁾pour d�clarer l?entit� id3 comme une relation de g�n�ralisation entre l?entit� id1 et l?entit� id2. Enfin, nous assignons des noms aux deux classes identifi�es par id1 et id2 en utilisant le pr�dicat nom_entit�()⁽⁴⁾.

Dans la suite de l?article nous adoptons les notations suivantes�: nous attribuons aux variables des noms commen�ant avec des ?_? et aux constantes des noms commen�ant avec des minuscules. Dans la section suivante, nous pr�sentons le processus de g�n�ration des sp�cifications sources.

Une sp�cification source est g�n�r�e � partir d?un diagramme de classes. Nous pr�sentons dans cette section les r�gles de g�n�ration des sp�cifications sources. Pour chacun des concepts que nous pouvons rencontrer dans un diagramme de classes (OMG, 2003), nous pr�sentons sa d�finition en terme de pr�dicats. Il est important de noter que toutes les clauses sont g�n�r�es avec des constantes�; cela est d� au fait que la sp�cification source d�crit des faits r�els qui se trouvent dans le diagramme de classes source.

Comme nous l?avons montr� dans la sp�cification partielle de la section�, nous d�clarons chacun des �l�ments de mod�lisation pr�sents dans un diagramme de classes avec le pr�dicat entit�(). Les noms des entit�s sont d�clar�s avec le pr�dicat nom_entit�().

Une classe est la description d?un ensemble d?objets qui partagent les m�mes attributs, op�rations, associations et la m�me s�mantique. Le pr�dicat classe() d�clare⁽¹⁾ �une classe. Une classe est d�finie par les attributs suivants�: nom⁽²⁾, abstraction(3)�(valeur bool�enne indiquant si une classe est abstraite).

Un attribut est une propri�t� structurelle d?une classe permettant � un objet de stocker des informations. Le pr�dicat attribut() d�clare ⁽⁴⁾ �un attribut et le pr�dicat classe_attribut() associe un attribut � la classe qui le d�clare⁽⁵⁾. Un attribut est d�fini ⁽⁴⁾ par les rubriques suivantes�: nom⁽¹⁾, type⁽²⁾ et valeur par d�faut⁽³⁾.

Une op�ration est une propri�t� comportementale d?une classe d�crivant un service offert par une classe ou une interface. Une op�ration est d�clar�e par le pr�dicat op�ration()⁽⁴⁾ et associ�e � la classe qui la d�clare par le pr�dicat classe_op�ration()⁽⁵⁾. Une op�ration poss�de une signature qui d�crit ses param�tres et sa valeur de retour. Une op�ration est d�finie par les attributs suivants�: nom de l?op�ration ⁽¹⁾, abstraction ⁽²⁾�(une valeur bool�enne qui indique si une op�ration est abstraite ou non) et signature ⁽³⁾.

Un param�tre est une variable qui peut �tre pass�e � une op�ration. Le pr�dicat param�tre() permet de d�clarer un param�tre⁽⁸⁾ et le pr�dicat signature_param�tre() permet de l?associer � une signature ⁽⁹⁾. Il est d�fini par les attributs suivants�: nom⁽¹⁾, type⁽²⁾, type de communication�(in (entr�e)⁽³⁾, out (sortie)⁽⁴⁾, in/out (entr�e sortie)⁽⁵⁾, return (valeur de retour) ⁽⁶⁾) et valeur par d�faut ⁽⁷⁾.

Une association d�finit une relation s�mantique entre Classifiers (interfaces, classes, etc.). Une association poss�de un nom⁽¹⁾ et au moins deux instances de AssociationEnd. Un seul classifier peut �tre connect� � plus d?un AssociationEnd dans une Association. Une association est d�clar�e avec le pr�dicat association()⁽²⁾. Le pr�dicat classe_associ�e() est utilis� pour d�clarer une �ventuelle classe d?association.

associationend sp�cifie la relation entre une association et un classifier. C?est l?extr�mit� d?une association. Elle indique les classifiers compatibles avec l?extr�mit� de l?association. Une associationend est d�clar�e par le pr�dicat associationend()(6). Une associationend est d�finie par les attributs suivants�:

• Agr�gation�prend l?une des trois valeurs suivantes�: none pour indiquer une association simple, aggregate ⁽³⁾ pour indiquer une agr�gation, composite ⁽⁴⁾ �pour indiquer �une composition,

• Navigabilit�⁽²⁾ est une valeur bool�enne indiquant si une associationend est navigable,

• Multiplicit�⁽⁵⁾ �donne le nombre d?instances cibles qui peuvent �tre associ�es avec une instance source dans une association,

• Nom de r�le⁽¹⁾�repr�sente le nom du r�le de l?associationend,

• Classifier�identifie les classifiers, interfaces ou classes, qui sont accept�s par une associationend.

R�alise est une relation reliant une classe � une interface. La classe doit poss�der toutes les m�thodes d�finies dans l?interface. Une relation de r�alisation est d�clar�e par le pr�dicat r�alise()⁽¹⁾ et associ�e � la classe et l?interface qu?elle relie par le pr�dicat r�alise_classe_interface()⁽²⁾.

Le st�r�otypage est un moyen de classification des �l�ments de mod�lisation. Un �l�ment de mod�lisation st�r�otyp� se comporte comme s?il est une instance d?une m�ta-classe virtuelle. Un st�r�otype est d�clar� par le pr�dicat st�r�otype() ⁽³⁾. Il est d�fini par son nom⁽²⁾ et l?�l�ment de mod�lisation qu?il st�r�otype. Un st�r�otype est associ� � un �l�ment de mod�lisation par le pr�dicat st�r�otype_�l�ment_mod�lisation()⁽¹⁾ .

Une interface est un ensemble d?op�rations nomm�es qui caract�rise le comportement d?une classe. Nous faisons le choix de repr�senter une interface comme �tant une classe st�r�otyp�e avec le st�r�otype ��interface��. Ce choix de mod�lisation permet d?�viter de red�finir les m�ta-connaissances pour l?h�ritage des attributs, des op�rations et des relations. Une interface est d�finie par son nom et ses op�rations.

La g�n�ralisation est une relation taxonomique entre un �l�ment g�n�ral et un �l�ment plus sp�cialis�. L?�l�ment le plus sp�cialis� est compl�tement compatible avec l?�l�ment g�n�ral (il poss�de ses associations, ses r�alisations, ses attributs et ses op�rations) et peut contenir d?autres informations. Une g�n�ralisation est d�clar�e par le pr�dicat g�n�ralisation()⁽¹⁾. Une g�n�ralisation est d�finie par les attributs suivants�: classifier p�re (interface ou classe), classifier fils (interface ou classe).

Une sp�cification cible d�crit la structure d?un composant qui doit �tre retrouv� dans une ou plusieurs sp�cifications sources. Le processus de g�n�ration des sp�cifications cibles reprend exactement les m�mes r�gles d�finies dans le processus de g�n�ration des sp�cifications sources en leur appliquant les transformations suivantes�:

Exemple�: la r�gle de g�n�ration qui concerne les interfaces devient�

Le m�canisme d?appariement de sp�cifications est un algorithme de r�solution de formules (sp�cifications cibles) en logique du premier ordre implant� par un prouveur de th�or�mes. Les processus de g�n�ration de sp�cifications pr�sent�s dans les sections 4 et 5 sp�cifient un diagramme de classes sous une forme d�clarative en utilisant la logique du premier ordre. Or, un concept comme la g�n�ralisation a une s�mantique plus large que le simple fait de relier deux classifiers (interfaces ou classes). La relation de g�n�ralisation propage les informations contenues dans le classifier g�n�ral (attributs, op�rations, associations, r�alisations) vers ses sp�cialisations. Lors de la phase d?appariement des sp�cifications, il faut tenir compte de cette m�ta-connaissance. L?id�e est de permettre � l?utilisateur de choisir les m�ta-connaissances qu?il veut utiliser lors de la phase d?appariement dans le but d?am�liorer les performances du syst�me. Par exemple, s?il s?int�resse uniquement aux relations qui existent entre les classes, il n?a pas besoin de la propagation des attributs et des m�thodes induites par les relations de sp�cialisation. Les m�ta-connaissances que nous pr�sentons dans cette section traitent les aspects s�mantiques de la g�n�ralisation et des techniques de relaxation de l?appariement pour am�liorer le rappel. �

La relation de g�n�ralisation entre deux classes implique la propagation des informations (relations, attributs, op�rations) de la classe la plus g�n�rale vers la classe sp�cialis�e.

La r�gle suivante d�crit la propagation des attributs dans une g�n�ralisation�:

La r�gle suivante d�crit la propagation des op�rations dans une g�n�ralisation�:

R�alise�: Si la classe g�n�rale r�alise une interface alors la classe sp�cialis�e r�alise aussi cette interface.

Si une classe r�alise une interface sp�cialis�e alors la classe r�alise forc�ment l?interface g�n�rale.

Association�: Si un classifier (interface ou classe) est reli� par une association � un autre classifier, alors sa sp�cialisation l?est aussi.

La clause de propagation des associations (association simple, agr�gation et composition) doit �tre utilis�e avec pr�caution car elle effectue une fermeture de toutes les associations. Elle doit donc �tre employ�e uniquement lorsque l?utilisateur d�sire retrouver tous les classifiers qui sont reli�s � un classifier source. Dans un contexte de r�ing�nierie simple, il est fortement conseill� de la d�sactiver.

Un processus de r�ing�nierie a pour but de d�tecter les sp�cifications des composants de la base de composants dans la sp�cification d?un syst�me d?information existant. Sans le m�canisme de relaxation, le processus d?appariement renvoie un r�sultat du type ��tout ou rien�� (composants d�tect�s ou non). Parfois, il est int�ressant de retrouver des parties qui ressemblent � quelques d�tails pr�s � des composants de la base. Nous appelons ce cas de figure un appariement relax�.

Une agr�gation est une association avec la s�mantique suppl�mentaire qu?une classe peut appartenir (par agr�gation) � une autre classe�; une composition est une agr�gation avec un crit�re d?exclusivit� suppl�mentaire.

Le fait qu?une composition et une agr�gation soient des associations est exprim� par les clauses de g�n�ration de sp�cifications d�j� pr�sent�es. La clause suivante exprime qu?une composition est un type particulier d?agr�gation.

Lors de la phase d?appariement, il est parfois int�ressant de retourner une op�ration dont la signature est une sp�cialisation ou une g�n�ralisation de la signature recherch�e par la sp�cification cible. Le pr�dicat suivant effectue la relaxation par sp�cialisation et on peut faire de m�me pour la relaxation par g�n�ralisation.

Nos travaux de recherche concernent actuellement l?�laboration d?un environnement de d�veloppement de syst�mes d?information par r�utilisation de composants. Cet environnement est con�u pour permettre aux utilisateurs de puiser des composants dans des bases de composants, de g�rer des bases de composants et de g�rer le cycle de vie des composants. Il inclut quatre sous-syst�mes�: un syst�me de gestion de bases descriptives de composants (SGBDC) (Khayati et al., 2004) un syst�me de recherche de composants (SRC), un gestionnaire de cycle de vie des composants (GCVC) et une interface d?administration. La technique que nous proposons s?int�gre dans un cinqui�me outil qui compl�te cet environnement de d�veloppement de syst�mes d?information par r�utilisation de composants. Cet outil permet de construire une base de sp�cifications � partir de la base de composants que nous utilisons pour r�aliser la r�ing�nierie de syst�mes d?information existants.

La fonctionnalit� principale de notre outil est la d�tection de la structure d?un composant cible (diagramme de classes cible) dans un diagramme de classes source. Le processus de r�ing�nierie que nous proposons (Figure 2) est compos� principalement de trois sous-processus�: le processus de g�n�ration de sp�cifications cibles, le processus de g�n�ration de sp�cifications sources et le processus d?appariement de sp�cifications. Chacun de ces processus a �t� pr�sent� dans les sections 4, 5 et 6.

L?implantation de notre outil utilise la technologie XSL pour transformer les diagrammes de classes (fichiers XMI) en programmes Prolog. Nous utilisons les sp�cifications sources pour g�n�rer les programmes et les sp�cifications cibles pour g�n�rer des cibles. Les r�gles de g�n�ration pr�c�demment pr�sent�es sont transform�es avec les r�gles suivantes pour g�n�rer des clauses Prolog�:

��

Dans un premi�re �tape, l?utilisateur l?utilisateur saisit des diagrammes de classes � l?aide d?un �diteur UML (l?AGL ArgoUML). La deuxi�me �tape (Figure 3) consiste � transformer ce diagramme de classes en une sp�cification formelle en Prolog.

Notre technique peut �tre exploit�e pour r�aliser d?autres t�ches que la r�ing�nierie d?un syst�me d?information�; par exemple pour assister l?ing�nieur de composants pour construire de nouveaux composants en r�utilisant des composants existants dans la base de composants, pour faire de la recherche de composants et pour promouvoir la r�utilisation. Nous pr�sentons dans les sous-sections suivantes ces trois cas d?utilisation.

Si nous rempla�ons les diagrammes de classes extraits � partir du syst�me d?information par un diagramme de classes exprimant les besoins d?un ing�nieur de composants (Figure 2), le processus d?appariement proposera une collection de composants qui aidera l?ing�nieur de composants � la construction d?un composant r�pondant � ses besoins, partiellement ou totalement. Ainsi, l?outil contribue � promouvoir la construction de nouveaux composants et donc la r�utilisation de composants.

En permutant les processus de ��g�n�ration de sp�cifications cibles�� et de ��g�n�ration de sp�cifications sources�� (Figure 2), nous obtenons un syst�me de recherche de composants par appariement de sp�cifications (Figure 4). L?outil utilisera le sc�nario classique d?interrogation de bases de composants � base de cibles. La structure du diagramme de classes utilisateur sera recherch�e dans la base de composants.

La technique propos�e permet de promouvoir la r�utilisation aupr�s des ing�nieurs d?application. Son int�gration dans un �diteur UML procure � l?�diteur la facult� d?analyser le diagramme de classes en cours de construction. Une fois une structure proche de celle d?un composant de la base de composant d�tect�e (gr�ce � des techniques de relaxation), l?�diteur pourra proposer � l?ing�nieur d?application de r�utiliser le composant.

Nous avons pr�sent� dans cet article une technique de sp�cification structurelle de diagrammes de classes UML en logique du premier ordre. Dans les sections 4 et 5, nous avons d�crit des processus de g�n�ration des sp�cifications cibles et sources. Dans la section 6, une technique d?appariement de sp�cifications a �t� d�velopp�e pour exploiter le calcul des pr�dicats pour prouver que les sp�cifications cibles sont une cons�quence logique des sp�cifications sources. La technique d?appariement utilise un ensemble de m�ta-connaissances pour diriger le processus de preuve. Enfin, la section 7 d�crit l?outil qui implante notre technique et les diff�rents champs d?application de cette technique.

L?int�r�t de notre approche par rapport � celles cit�es r�side dans le fait que nous nous int�ressons � la structure et aux signatures des composants. De plus, notre approche est applicable � des composants conceptuels et logiciels. Le processus de r�ing�nierie est donc applicable aux niveaux conceptuel et logiciel. La technique propos�e est souple et plus facile � utiliser puisque l?utilisateur ne manipule pas (ou presque pas) les sp�cifications logiques. En effet, il d�crit ses cibles sous forme de diagrammes de classes et l?outil g�n�re la sp�cification automatiquement. Nous devons d�sormais poursuivre l?�tude de cette technique de g�n�ration et d?appariement de sp�cifications structurelles et nous nous sommes fix�es des objectifs � court et � long terme. � court terme, il convient de tester l?efficacit� de notre approche sur une large collection de composants. Cette exp�rimentation permettra d?identifier de nouvelles m�ta-connaissances sp�cifiques � la t�che dans laquelle notre technique est utilis�e. � long terme, il est n�cessaire d?�tendre cette technique � tout le m�ta-mod�le UML (OMG, 2003) et de traiter les autres types de diagrammes UML.