Extraction d’architectures intentionnelles depuis la documentation

Comme nous l’avons vu, les informations contenues dans la documentation ne sont pas immédiatement disponibles pour un traitement automatique. Nous proposons donc un processus permettant d’extraire une vue de l’architecture intentionnelle à partir des différents documents que l’on prend en compte dans notre approche. Nous utilisons ensuite cette architecture intentionnelle pour réduire l’espace de recherche de notre processus d’extraction.

Cependant, nous avons montré, à travers les exemples de la section précédente, que l’extraction de l’architecture intentionnelle est difficile manuellement. Elle nécessite une profonde étude du système et des documents et il semble donc difficile de proposer un processus automatique et complet d’extraction des informations contenues dans les documents. En conséquence, nous présentons, dans la suite, un processus heuristique et semi-automatique basé sur les validations, vérifications et conseils de l’architecte en plus de la documentation.

Dans la suite, nous exposons d’abord les aspects de notre processus qui s’appliquent à tous les types de documents. Nous abordons ensuite, les aspects de notre processus spécifiques à chaque type de docu- ments.

5.2.1 Processus de partitionnement

L’objectif de l’extraction de l’architecture intentionnelle peut être ramené à l’extraction d’une partition des classes du système à partir des documents. Cette partition peut ensuite être projetée sur le modèle d’informations de ciblage en associant à chaque partie un contour de composant.

Ce calcul de partition repose sur les mêmes étapes quelque soit le type de document concerné. Les as- pects communs à ce calcul de partition sont donc les deux étapes de notre processus de partitionnement : une étape de regroupement puis une étape de partition proprement dite.

5.2.1.1 Étape de regroupement

L’étape de regroupement consiste en un regroupement hiérarchique des classes du système. Le principe de l’algorithme de regroupement hiérarchique (défini par S.C.Johnson [68]) est donné dans la figure 5.5 A. Au démarrage, l’algorithme de regroupement hiérarchique considère que chaque élément initial constitue un groupe (ligne 4). Ensuite, à chaque étape, les deux groupes les plus similaires (fonction

clusterP roche) sont regroupés dans un nouveau groupe (lignes 5 à 10). Le processus se termine lorsqu’il

ne reste plus qu’un seul groupe. A partir de ce dernier groupe, on obtient une représentation en forme de dendrogramme de la hiérarchie des groupes (ligne 11). La figure 5.5 B présente la forme du résultat de cet algorithme. Dans cet exemple, les étapes du regroupement sont (a,c), (a,c,e), puis (b,d) et enfin (a,b,c,d).

Figure 5.5 – Algorithme de regroupement hiérarchique

Nous exploitons cet algorithme pour regrouper les classes objets du système en utilisant une fonction de similarité spécifique à chaque type de documents. Cette fonction permet de mesurer le niveau de dépendances ou de collaboration entre deux classes. La valeur de cette fonction est donc évaluée sur chaque paire de classes à l’initialisation du processus. Par la suite, la similarité entre deux groupes est la moyenne de leurs similarités.

5.2.1.2 Étape de partitionnement

Pour obtenir une partition des classes du système, on doit sélectionner des nœuds dans la hiérarchie résultant de l’étape précédente. Cette sélection est réalisée par l’algorithme détaillé dans la figure 5.6 qui sélectionne les nœuds présentant la plus forte similarité.

L’algorithme de sélection des nœuds consiste en un parcours en profondeur du dendrogramme (pa- ramètre dendro). A chaque nœud, on compare la valeur de similarité S des éléments qui constituent ce groupe avec celle de ses deux fils (ligne 9). Si la valeur de similarité de ce nœud est inférieure à la moyenne de ses deux fils, alors l’algorithme traite le premier fils (lignes 12 et 13), sinon le nœud courant est identifié comme un contour et ajouté à la partition (variable R, ligne 10) et l’algorithme traite ensuite le nœud suivant.

5.2.1.3 Processus de validation des informations

L’architecte peut intervenir à différents moments durant le calcul de la partition des classes : avant la première étape, entre les deux étapes et après la deuxième étape. Chacune de ces interventions a une influence directe sur la confiance accordée au résultat de l’extraction (cf. Figure 5.7) :

• il peut rejeter les informations en considérant qu’elles ne sont pas suffisamment fiables pour être

Figure 5.6 – Algorithme de partitionnement du dendrogramme

• il peut ignorer les informations. C’est le choix par défaut si aucun architecte n’est disponible.

Dans ce cas, il ne souhaite pas s’exprimer à ce niveau et ne prend aucune décision ;

• Il peut également influencer directement le processus. Avant l’étape de regroupement, il peut

modifier le calcul de similarités entre les classes. Par exemple, il peut évaluer que la similarité entre deux classes est plus forte que celle mesurée ou inversement. Avant l’étape de partitionnement, il peut également modifier le dendrogramme résultat pour l’ajuster à ces attentes. Il peut ainsi modifier les relations hiérarchiques entre les groupes et donc les liens entre les classes. Enfin, après le partitionnement, il peut modifier la partition résultat pour l’ajuster à ses attentes. Il peut ainsi modifier les contours de composants ou déplacer des méthodes vers les contours de connecteurs pour signaler les connecteurs qu’il suppose ;

• il peut simplement valider les résultats de l’étape et accorder une confiance maximale au mode

de calcul automatique.

Cette confiance comporte trois niveaux. Le premier correspond à une absence de confiance, il est atteint si l’architecte rejette les informations. Le second niveau est le niveau par défaut. Il correspond aux informations ignorées par l’architecte. Enfin, le dernier niveau correspond à une confiance totale. Elle est atteinte lorsque l’architecte valide ou modifie les résultats du processus d’extraction.

5.2.2 Mesure de similarité dans la documentation

Si l’algorithme d’extraction de l’architecture intentionnelle est le même pour tous les types de docu- ments, la différence provient de la métrique utilisée dans le déroulement du processus. Selon les types de documents, la proximité entre les classes se mesure de manière différente et donne lieu à des mesures de similarités très diverses.

Nous proposons, ici, les mesures de similarité concernant les trois types de documents que nous avons sélectionnés : les diagrammes UML, le code source et les outils de versionnement.

Il est clair à travers notre démarche que l’on peut aisément prendre en compte un nouveau type de documents en proposant simplement une mesure de similarité spécifique. Ceci rend notre approche

facilement extensible.

5.2.2.1 La similarité dans les diagrammes UML

Face à la richesse de ce type de document, nous concentrons nos efforts sur l’extraction des infor- mations concernant les classes et leur relations. Pour cela, nous sommes naturellement amenés à prendre en considération les objets, qui sont directement liés aux classes, et les cas d’utilisation qui sont liés aux classes ou aux objets à travers les fonctionnalités représentées par les différents diagrammes.

Nous utilisons donc les diagrammes qui comportent les entités qui nous intéressent pour établir un graphe de dépendances entre ces entités. Nous créons ensuite un graphe de dépendances entre les classes. Enfin, nous utilisons ce graphe pour mesurer la similarité entre les classes.

Les diagrammes UML. Nous concentrons nos efforts sur une partie seulement des diagrammes UML. En effet, les diagrammes UML sont variés et traitent chacun un aspect de la modélisation du logiciel. Ainsi, les entités présentes dans les diagrammes sont diverses et ils ne contiennent pas tous l’ensemble des entités qui nous intéressent. Par conséquent, nous utilisons les six types de diagrammes suivants :

• les diagrammes de classes et objets : ces diagrammes contiennent respectivement des informa-

tions sur les classes et les objets. En effet, un diagramme de classes (ou objets) est une représen- tation graphique de la vue statique qui montre une collection d’éléments statiques (dynamiques) du modèle du système, comme des classes, des types et leurs contenus et relations (des objets et leurs relations). Ces diagrammes contiennent également certains éléments comportementaux réifiés, comme des opérations ;

• les diagrammes de cas d’utilisation : ces diagrammes contiennent des informations sur les cas

d’utilisation. En effet, ils modélisent la fonctionnalité d’un système telle qu’elle est perçue par un ou plusieurs intervenants extérieurs, appelées acteurs. Le diagramme liste les acteurs et les cas d’utilisation et montre les acteurs participant à chaque cas d’utilisation. Il montre également les relations entre les cas d’utilisation, en particulier les relations d’inclusion ;

• les diagrammes de séquences : ces diagrammes contiennent des informations sur les objets et

les cas d’utilisation. Ils montrent un ensemble de messages organisés en séquences temporelles. Chaque rôle est présenté par une ligne de vie qui représente le rôle dans le temps à travers l’in- teraction globale. Les messages apparaissent sous forme de flèches entre les lignes de vie. Ce diagramme illustre un scénario correspondant à un cas d’utilisation ;

• les diagrammes de communication : comme les diagrammes de séquences, ces diagrammes

contiennent donc des informations sur les objets et les cas d’utilisation. Ils illustrent les mêmes interactions que les diagrammes de séquence. Cependant, ils s’attachent à montrer un aspect dif- férent de l’aspect temporelle proposé par les diagrammes de séquence. Ainsi ils s’attachent plus particulièrement aux relation entre les rôles. Ceci sont donc représentés par des rectangles alors que les messages sont associés à des arcs entre les rectangles. L’ordre des messages est alors re- présenté par une numérotation des arcs ;

• les diagrammes de collaborations : il contient des informations sur les classes, les objets et les

cas d’utilisation. Il affiche la définition d’une collaboration. Il décrit les entités impliquées dans la réalisation d’une fonctionnalité associée à un cas d’utilisation.

La mesure de similarité. La mesure de la similarité dans les diagrammes UML repose sur le graphe de dépendances entre les classes. Ce graphe est calculé à partir du graphe de dépendances entre entités objets. La similarité entre deux classes a et b est égale à la pondération de l’arête{a, b} reliant ces deux classes dans le diagramme de dépendances entre les classes.

Le graphe des dépendances entre entités objets. Le graphe des dépendances est un graphe non- orienté et pondéré Ga(V, E, w), où l’ensemble des sommets V contient toutes les entités objets qui nous

intéressent, i.e. classe, objet et cas d’utilisation, et l’ensemble des arêtes E contient une arête{a, a0} si les entités a et a0sont liées dans un diagramme.

La fonction w assigne un poids à chaque arête. Ce poids est le nombre de diagrammes où les entités, représentés par les sommets des arêtes, sont liées. L’architecte peut influer sur cette pondération en attri- buant un poids aux différents diagrammes. Il peut ainsi modifier l’importance relative des diagrammes.

Deux entités sont liées dans un diagramme s’il existe dans le diagramme une arête entre les repré- sentations des deux entités. Il existe également un lien entre deux entités si la représentation de l’une est incluse dans la représentation de l’autre dans un diagramme. Enfin, il existe un lien, représenté par une arête de poids nul, entre un objet et la classe dont elle est instance.

Le graphe de dépendance entre classes. Le graphe des dépendances des classes est un graphe non-orienté et pondéré Gc(V, E, w), où l’ensemble des sommets V contient toutes les classes, et l’en-

semble des arêtes E contient une arête{a, a0} s’il existe un chemin entre les sommets a et a0 dans Ga.

La fonction w assigne un poids à chaque arête. Ce poids est la somme de tous les chemins reliant les deux sommets. Cette valeur représente la force des dépendances entre les deux classes dans l’ensemble des diagrammes UML pris en compte. De plus, les choix de l’architecte sur le poids à affecter à chaque diagramme a une influence directe sur la similarité des classes.

5.2.2.2 La similarité dans les fichiers sources

Les commentaires et les noms des entités qui constituent le code source sont choisis avec attention par les programmeurs. Les commentaires illustrent les fonctionnalités associées à chaque entité alors que les noms des entités reflètent leur utilisation. Ces informations nous informent sur la sémantique associée aux classes et nous permettent de les regrouper en fonction de la similarité de la sémantique associée à chacune.

La mesure de similarité dans le code source est définie selon une analyse de sémantique latente (Latent Semantic Analysis, LSA) [79]. C’est une technique mathématique et statistique, totalement au- tomatique, pour l’extraction et l’inférence de relations d’usage conceptuel de mots dans un ensemble de textes. Elle a déjà été utilisée avec de bons résultats dans plusieurs approches qui s’appuient uni- quement sur la sémantique embarquée dans le code source pour documenter [35] ou proposer une vue architecturale d’un système [76, 126].

Les principes de LSA. La première étape consiste à modéliser le corpus de textes par une matrice des occurrences dans laquelle chaque ligne représente un terme unique et chaque colonne représente un des textes du corpus. Chaque cellule contient la fréquence d’apparition du mot de la ligne dans le texte de la colonne. Cette fréquence peut être pondérée par une fonction exprimant l’importance d’un terme dans un passage ou un domaine particulier.

Dans la deuxième étape, LSA décompose la matrice selon un processus de décomposition en valeurs singulières (singular value decomposition, SVD). Selon cette décomposition, une matrice rectangulaire

X est décomposée en un produit de trois autres matrices (cf. Equation 5.1). Les matrice W et P décrivent

respectivement les entités des lignes et des colonnes de la matrice initiale comme des vecteurs orthogo- naux : ceux sont les matrices des vecteurs propres « termes » et « documents ». La troisième matrice S est une matrice diagonale contenant les valeurs singulières de M .

La multiplication des trois matrices issues de la décomposition permet de reconstruire la matrice M originale. Mais, lorsqu’on sélectionne les k plus grandes valeurs singulières, ainsi que les vecteurs singu- liers correspondants dans W et P , on obtient une approximation de rang k de la matrice des occurrences. En faisant cette approximation, les vecteurs « termes » et « documents » sont traduits dans l’espace des « concepts ». Le nombre k des coefficients conservés peut être choisi par l’utilisateur ou calculé selon les dimensions de la matrice des occurrences.

Du code source à la matrice des occurrences. Afin d’utiliser l’algorithme LSA, nous devons d’abord générer la matrice des occurrences à partir du code source. Chaque fichier représente un document et chaque mot du fichier représente un terme de la matrice des occurrences. Cependant, cette correspon- dance entre les mots du fichier et les termes de la matrice des occurrences n’est pas directe. En fait, nous procédons à deux étapes pour augmenter la pertinence des termes extraits :

• le filtrage : pour réduire le bruit parmi les termes extraits, nous procédons à un filtrage des mots

du fichier. Tous les fichiers d’un système utilisant le même langage, nous filtrons les mots réservés du langage. Le bruit est également introduit par les noms de variables trop communs. Pour limiter cet effet, nous filtrons les mots contenus dans tous les fichiers. Nous filtrons également les mots contenant seulement des caractères de ponctuation ou ceux contenant seulement un caractère ;

• la césure : les noms de variables sont, la plupart du temps, constitués de plusieurs mots possédant

chacun une part d’information. L’utilisation directe des noms de variables nous empêche donc d’identifier les variables qui sont similaires. Par exemple, contains_key et key_contains sont simi- laires et contiennent les mêmes mots cependant les noms de ces deux variables sont différents. Pour éviter ceci, les noms des variables sont coupés en leurs différents constituants en utilisant les caractères tels que les soulignés, les tirets, les capitales (comme dans «replaceNamespaceSep») ou encore les chiffres.

Après ces deux étapes, la matrice des occurrences peut être construite avec les termes extraits et les fichiers de classes. La fréquence de chaque cellule est calculée selon l’équation suivante, où t est un terme, d un document, tft est la fréquence du terme t dans le document d,|D| est le nombre total de

documents et|{t ∈ d}| est le nombre de documents contenant le terme t :

wt,d= tft· log_{|{t ∈ d}|}|D| (5.2)

De la matrice des occurrences à la mesure de similarité Nous appliquons LSA à la matrice des occurrences que nous venons de présenter. Nous avons choisi de conserver k coefficients, où k est calculé selon les dimensions de la matrice (n∗ m) comme : k = (n ∗ m)0.2.

Le résultat de LSA nous permet de calculer une mesure de similarité entre deux classes j et q. La similarité est basée sur le cosinus de l’angle θ formé par le vecteur correspondant à chaque document représentant j et q dans la matrice, ~djet ~dq. Ce cosinus est calculé suivant la formule suivante :

cos θ = d~j· ~dq

~dj · ~dq

(5.3)

La figure 5.8 présente trois méthodes extraites de classes Java. En considérant que chaque méthode représente une classe et un fichier différent, nous souhaitons appliquer LSA pour calculer la similarité entre ces méthodes. Pour cela, nous appliquons d’abord les deux étapes qui nous permettent de générer la matrice des occurrences. Ainsi, après le filtrage des mots clefs de Java et la césure des termes présents dans les documents, nous obtenons une matrice des occurrences de 26 termes et 3 documents (cf. Tableau 5.2).

L’application de LSA sur cette matrice des occurrences a pour résultat une matrice reconstruite, repré- sentée par le tableau 5.3. Cette matrice fait apparaitre des relations entre les termes qui ne sont pas présentes dans la première matrice. LSA semble donc avoir fait apparaitre des relations sémantiques entre les termes qui n’étaient pas visibles de prime abord.

Enfin, nous utilisons la matrice reconstruite pour calculer les mesures de similarité entre les trois mé- thodes. Pour cela, nous calculons le cosinus de l’angle formé par les vecteurs représentant chaque do- cument. La mesure de la similarité est alors résumée dans le tableau 5.4

terme Docu 1 Docu 2 Docu 3

replace 0.17 0 0.35 namespace 0.17 0 0.17 sep 0.17 0 0.17 get 0.70 0.17 0 method 3.82 0 0 name 0.35 0 O.85 signature 5.25 0 0 cache 1.43 0 0 contains 0.17 0 0.17 key 0.17 0 0.17 type 0.48 0 0 params 1.43 0 0 argument 0.48 0 0 types 0.48 0 0 length 0.48 0 0 sig2cn 0.48 0 0 put 0.17 0 0.17 as 0 0.48 0 invocation 0 0.96 0 id 0 0.96 0 buffer 0 0.48 0 fm 0 0.48 0 append 0 1.92 0 to 0 0.48 0 rns 0 0 1.44 all 0 0 0.48

Table 5.2 – La matrice des occurrences

terme Docu 1 Docu 2 Docu 3

replace 0.17 0.05 0.49 namespace 0 0 0.02 sep 0.35 0 0 get 0.17 0.09 0.97 method 0 0 0.05 name 0.17 0 O signature 0.17 0.09 0.95 cache 0.01 0.01 0.14 contains 0.17 0 0 key 0.7 0.04 0.48 type 0.17 0 0.05 params 0 0 0 argument 3.82 0.01 0.48 types 0 0 0.05 length 0 0 0 sig2cn 0.35 0.19 1.90 put 0 0 0.05 as 0.85 −0.01 0 invocation 5.25 0 0.48 id 0 0 0.05 buffer 0 0 0 fm 1.43 −0.01 0 append 0 0.14 1.44 to 0 0 0 rns 0.17 0 0.02 all 0 0.05 0.48

Méthode 1 Méthode 2 Méthode 3

Méthode 1 1 0.31 0.44

Méthode 2 0.31 1 0.71

Méthode 3 0.44 0.71 1

Table 5.4 – Mesure de similarité entre les méthodes exemples

La mesure de similarité est maximale entre les méthodes 2 et 3. L’étude détaillée des trois méthodes permet de comprendre ces résultats. Les trois méthodes réalisent des traitements sur des chaines de ca- ractères. Cependant, les deux dernières méthodes travaillent sur des chaines de caractères quelconques alors que la première travaille sur des entités plus spécifiques : des chaines de caractères représentant la définition d’une méthode.

Ainsi, la première méthode utilise une approche légèrement différente des deux dernières. Cette différence n’est pas évidente à première vue. Mais l’application de LSA nous a permis de mettre en évidence cette plus grande similarité entre les deux dernières méthodes qu’entre ces méthodes et la première.

5.2.2.3 La similarité dans les archives des outils de versionnement

Les outils de versionnement archivent de nombreuses informations sur le système dont ils encadrent le développement ou la maintenance. Au delà des différentes versions du système, ces outils archivent aussi les dates, les auteurs et les cibles des modifications. Ces informations permettent de suivre les modifications apportées à un moment donné à un ensemble de classes par une personne.

Or, lorsqu’un programmeur doit ajouter une fonctionnalité ou apporter une modification, il modifie de manière rapprochée l’ensemble des classes concernées par cette modification. Ainsi, les informations