Extraction d’Architecture à Base de Composants d’un Système Orienté Objet Sylvain Chardigny* — Abdelhak Seriai* — Mourad Oussalah** Dalila Tamzalit** * Ecole des Mines de Douai

941 rue Charles Bourseul, F-59508 Douai {seriai, chardigny}@ensm-douai.fr ** Lina, université de Nantes

2 rue de la Houssinière, F-44322 Nantes {oussalah, tamzalit}@lina.univ-nantes.fr

RÉSUMÉ. Disposer d’une représentation de l’architecture d’un système complexe est devenue essentiel pendant toutes les phases du cycle de vie du logiciel. Cependant pour beaucoup de systèmes, aucune représentation fiable de leurs architectures n’est disponible. Afin de palier cette absence, source de nombreuses difficultés, nous proposons, dans cet article une approche visant à extraire une architecture à base de composants à partir d’un système orienté objet existant. L’idée première de cette approche est de proposer un processus semi-automatisé d’identification des composants d’un système en se basant sur leurs caractéristiques sémantiques et structurelles. Nous proposons une approche quantitative de ces caractéristiques.

Having a representation of the architecture of complex systems became predominant during all the software life cycle phases. However, for many systems, there is no reliable representation of their architectures available.In order to avoid this lack which causes many difficulties, we suggest, in this paper, an approach aiming at extracting component-based architectures from object-oriented systems. The main idea of this approach is to propose a semi-automated identification process of components based on their semantic and structural characteristics.

ABSTRACT.

MOTS-CLÉS : architecture logicielle, extraction, composants logiciels, orienté objet, rétroingénierie, métriques KEYWORDS: Software architecture, extraction, software component, object-oriented, reverse engineering, metrics

Inforsid 2007, pages 1 à 16

2

Inforsid 2007

1. Introduction La modélisation et la représentation de l’architecture logicielle des systèmes complexes est devenue, aujourd’hui, une phase importante de leurs processus de développement (Bertolino et al., 2005). L’architecture d’un système décrit sa structure à un haut niveau d’abstraction, en terme de composants et de connecteurs. Cette abstraction offre de nombreux avantages tout au long du cycle de vie du logiciel (Shaw et al., 1996). En effet, disposer d’une représentation de l’architecture facilite les échanges entre les concepteurs et les programmeurs. Ensuite, pendant les phases de maintenance et d’évolution, cette représentation permet de localiser les défauts du logiciel et réduit les risques lors de l’ajout d’une nouvelle fonctionnalité. En plus, une architecture à base de composants offre d’autres avantages. En effet, en utilisant cette représentation, la distinction entre les composants et les connecteurs rend explicite la séparation entre les aspects métiers et communications et facilite la compréhension et l’évolution du système. L’architecture à base de composants est également essentielle pour faciliter la réutilisation de certaines parties du système représentées par les composants. Cependant, force est de constater, que beaucoup de systèmes existants ne disposent pas d’une représentation fidèle de leur architecture. En effet, le système peut avoir été conçu sans considérer la notion d’architecture, comme dans le cas de certains systèmes patrimoniaux. Pour d’autres systèmes, la représentation disponible peut être décalée par rapport à l’implémentation du système. Ce décalage apparaît avec les écarts entre l’architecture prévue et implémentée puis s’accroît avec le manque de synchronisation entre la documentation et l’implémentation. Partant de ces constats, nous nous sommes intéressés, dans le cadre du développement du système ROMANTIC1 , au développement d’une approche permettant d’extraire l’architecture à base de composants d’un système orienté objet. Cette approche utilise différents guides tels que la sémantique de l’architecture ou ses propriétés de qualité. Dans la suite de cet article, nous présentons cette approche d’extraction d’architecture comme suit. La section 2 présente une vue générale de notre approche. Les caractéristiques sémantiques des composants seront détaillées dans la section 3. Notre algorithme d’extraction ainsi qu’un cas d’étude sont présentés, respectivement, dans les sections 4 et 5. Enfin, les travaux apparentés et une conclusion sont présentés, respectivement, dans les sections 6 et 7.

2. Principes d’extraction de l’architecture d’un système orienté objet L’architecture à base de composants d’un système est une abstraction à un haut niveau de ce dernier. Sa conception consiste à déterminer ses éléments architecturaux, 1. ROMANTIC : Re-engineering of Object-oriented sytesMs by Architecture extractioN and migraTIon to Component based ones.

Extraction de l’architecture

3

c’est à dire les composants qui définissent les traitements métiers, les connecteurs qui décrivent les communications entre ces composants et la configuration qui représente la topologie des liens entre les composants. L’extraction d’une architecture est le processus inverse de celui de sa conception. Au lieu d’utiliser les connaissances de l’architecte pour créer une architecture et l’implémenter, le processus d’extraction utilise ses connaissances pour obtenir une abstraction du système à partir de son implémentation. Notre objectif, dans cet article est de proposer une approche d’extraction d’une architecture basée sur les composants à partir de l’implémentation d’un système orienté objet. Notre approche s’appuie, pour cela sur deux principes : le premier nous permet de déterminer quels ensembles d’éléments de l’implémentation orienté objet du système peuvent être considéré comme des éléments architecturaux. Le deuxième définit les éléments de contrôle qui peuvent guider notre processus.

2.1. Principe n˚1 : Extraction d’une architecture à base de composants à partir d’un système orienté objet (a)

(b)

Figure 1. Modèle de correspondance objet-composant L’identification des éléments architecturaux nécessite l’établissement d’un modèle de correspondance entre les concepts architecturaux (i.e. composants, connecteurs, interfaces, etc.) et ceux du monde objet (i.e. classes, interfaces, paquetages, etc.). Nous proposons le modèle de correspondance suivant : – identification des composants : un composant correspond à un ensemble de classes qui peuvent appartenir à différents paquetages objets. Chacun de ces ensembles est appelé «contour». Nous appelons «interface du contour» l’ensemble des classes du contour qui ont un lien avec des classes se trouvant à l’extérieur de celui-ci, i.e. un appel de méthode vers ou depuis l’extérieur du contour (cf. fig.1.a). Nous assimilons l’ensemble des interfaces du composant à l’interface du contour (cf. fig.1.b) ;

4

Inforsid 2007

– identification des connecteurs : nous avons choisi de nous concentrer en premier lieu sur l’identification des composants. Pour cela, nous supposons, dans ce papier, que les connecteurs sont des liaisons simples entre deux composants ; – identification de la configuration : la configuration de l’architecture est associée à l’ensemble des contours identifiés. Afin d’éviter le problème de la duplication d’objets dans plusieurs composants, nous imposons que chaque classe doit appartenir à un seul et unique contour. Par conséquent, la configuration constitue une partition des classes du système ;

2.2. Principe n˚2 : éléments de contrôle du processus d’extraction

Figure 2. Les guides de l’extraction Pour extraire une architecture la plus pertinente possible nous avons déterminer un ensemble d’éléments nous permettant de guider le processus d’extraction. Ces éléments sont les suivants (cf. fig.2) : – l’implémentation définit la structure et le comportement du système. Nous devons uniquement abstraire de cette implémentation une architecture ; – la sémantique associée à la notion d’architecture permet de matérialiser les connaissances de l’architecte et guider notre processus d’extraction ; – les propriétés de qualité d’une architecture peuvent être utilisées pour matérialiser le style et les priorités de l’architecte ; – les documents de conception peuvent être utilisés pour guider notre processus en fonction des fonctionnalités du système ; – les recommandations de l’architecte, considéré comme un acteur de notre approche, peuvent influencer notre extraction.

Extraction de l’architecture

5

Cependant, parmi ces guides, celui qui utilise la sémantique des éléments architecturaux nous semble prépondérant. C’est pourquoi, nous nous focalisons dans ce travail sur l’étude de ce guide et son utilisation dans notre processus d’extraction.

3. Étude de la sémantique des composants logiciels La notion d’architecture logicielle est définie à travers ses éléments architecturaux. Une architecture sémantiquement correcte est donc une architecture dont les éléments respectent un ensemble de caractéristiques sémantiques. Ainsi, nous étudions, dans la suite, les caractéristiques sémantiques des composants, et nous définissons des fonctions pour les mesurer. Enfin, nous utilisons ces fonctions pour définir une fonction d’évaluation de la validité sémantique des composants.

3.1. Sémantique d’un composant logiciel Il existe de nombreuses définitions qui caractérisent un composant, parfois différemment. Néanmoins, il existe d’importantes similitudes parmi les définitions les plus courantes. Ainsi, Szyperski définit un composant comme une unité de composition possédant des interfaces spécifiées par contrat et des dépendances explicites avec le contexte. Il peut être déployé indépendamment et peut être composé par un tiers (Szyperski, 1998). Heinemann et Councill définissent un composant comme un élément logiciel qui est conforme à un modèle de composant et peut être déployé indépendamment et composé sans modification selon un standard de composition (Heinemann et al., 2001). Enfin Luer définit un composant comme un élément logiciel qui (a) encapsule une implémentation réutilisable d’une fonctionnalité, (b) peut être composé sans modification et (c) adhère à un modèle de composant. Il distingue cette définition de celle d’un composant déployable qui est un composant (a) pre-paquetagé, (b) distribué indépendamment, (c) facile à installer et désinstaller et (d) auto-descriptif (Luer et al., 2002). En combinant et en raffinant les éléments communs de ces définitions ainsi que ceux d’autres définitions généralement admises, nous obtenons la définition suivante du composant : Un composant est un élément logiciel qui (a) est composable sans modification, (b) peut être distribué de manière autonome, (c) encapsule une fonctionnalité, et (d) qui adhère à un modèle de composant. Nous utilisons pour définir le modèle d’un composant, la définition donnée dans (Luer et al., 2002) : un modèle de composant est la combinaison de (a) un standard de composant qui gouverne la construction de chaque composant et (b) un standard de composition qui régit comment organiser un ensemble de composants en une application et comment ces composants communiquent et interagissent entre eux. Ainsi, on retrouve dans cette définition le critère de Heimann sur l’adhésion à un standard de composition ainsi que les propriétés de Luer sur l’auto-description, le pré-paquetage ou encore la facilité d’installation/désinstallation qui sont régis par le standard de composant.

6

Inforsid 2007

En conclusion, d’après notre définition d’un composant, nous avons identifié trois caractéristiques sémantiques des composants : la composabilité, l’autonomie et la spécialisation.

3.2. Évaluation de la validité sémantique de composants logiciels Dans la section précédente, nous avons identifié trois caractéristiques sémantiques des composants que nous proposons d’évaluer. Pour cela, nous utilisons le modèle de mesure proposé par la norme ISO-9126 (ISO/IEC-9126-1, 2001) (cf. fig.3.a). Suivant cette norme, une caractéristique peut être mesurée en identifiant ses souscaractéristiques et pour chacune d’elles définir ses propriétés et les métriques permettant de mesurer ces dernières.

Figure 3. Modèle d’une caractéristique d’un produit logiciel dans la norme ISO-9126 et dans notre approche Ainsi, pour chaque caractéristique sémantique du composant, nous définissons un ensemble de propriétés mesurables à partir d’un certain nombre de métriques de composant. Cependant, pour la mesure de ces propriétés, nous proposons d’utiliser un ensemble de métriques sur les contours. Pour cela nous relions les propriétés des composants à un ensemble de propriétés mesurables des contours et nous donnons les métriques permettant de mesurer ces dernières (cf. fig.3.b). 3.2.1. Caractéristiques sémantiques vs. propriétés des composants L’analyse des caractéristiques sémantiques des composants nous a permis d’établir les liens suivants entre ces caractéristiques et les propriétés mesurables des composants : – spécialisation : il est difficile de déterminer à partir du code combien de fonctionnalités différentes un composant fournit. Cependant, plusieurs propriétés peuvent

Extraction de l’architecture

7

permettre de s’en faire une idée : un composant qui fournit de nombreuses interfaces fournit probablement différentes fonctionnalités ; une interface dont les services sont très cohérents fournit probablement une seule fonctionnalité ; un ensemble d’interfaces très cohérentes a plus de chance de fournir un nombre limité de fonctionnalités ; si le code du composant est très couplé, il fournit probablement un nombre réduit de fonctionnalités ; si le code du composant est très cohérent, il fournit probablement un nombre réduit de fonctionnalités. Ainsi, nous proposons de lier la caractéristique spécialisation aux propriétés suivantes : le nombre d’interfaces fournies, la moyenne des cohésions entre les services dans une interface, la cohésion entre les interfaces, le couplage et la cohésion à l’intérieur du composant ; – autonomie : un composant est complètement autonome s’il ne possède pas d’interface requise. La caractéristique autonomie peut donc être mesurée à travers la propriété « nombre d’interfaces requises » ; – composabilité : un composant est considéré comme composable d’abord parce qu’il définit clairement les services qu’il fournit et ceux qu’il requiert, cela se fait par la notion d’interfaces fournies ou requises. Cependant, il est évident qu’un composant sera plus facile à assembler avec un autre si, dans chacune de ses interfaces, les services sont cohérents. Ainsi la propriété «cohésion des services dans chaque interface» permet de mesurer cette caractéristique ;

Figure 4. Liens entre caractéristiques sémantiques d’un composant et ses propriétés Le tableau de la figure 4 résume ces relations. Une cellule contient : un « + » si l’amélioration de la propriété améliore la caractéristique, un « - » si elle la dégrade. 3.2.2. Propriétés des composants vs. propriétés des contours Afin de mesurer les propriétés de composants, nous avons établi leurs liens avec les propriétés mesurables des contours (cf. Fig.5) : – moyenne des cohésions des services de chaque interface du composant : d’après notre modèle de correspondance (cf. fig.1), l’ensemble des interfaces du composant est en correspondance avec l’interface du contour. On peut donc considérer que la moyenne des cohésions de chaque classe de l’interface donne une bonne idée de la moyenne des cohésions des services dans chaque interface du composant. Ainsi, nous utilisons la moyenne des cohésions de chaque classe de l’interface du contour pour mesurer cette propriété ; – cohésion entre les interfaces du composant : nous associons cette propriété à la propriété du contour mesurant la cohésion des classes de son interface ;

8

Inforsid 2007

Figure 5. Liens entre les propriétés du composant et les propriétés du contour

– cohésion et couplage interne du composant : la mesure de cette propriété du composant peut se faire en mesurant la cohésion ou le couplage des classes du contour ; – nombre d’interfaces fournies du composant : nous considérons, ici, qu’on associe à chaque classe de l’interface du contour qui possède une méthode publique, une interface fournie du composant. Grâce à cette hypothèse, nous pouvons mesurer le nombre d’interfaces fournies avec le nombre de classes de l’interface du contour qui possèdent une méthode publique ; – nombre d’interfaces requises par le composant : cette propriété peut être évaluée en utilisant le couplage du composant avec l’extérieur. Ce couplage est lié au couplage externe du contour. Nous pouvons donc mesurer le nombre d’interfaces requises du composant en utilisant le couplage externe du contour ;

3.3. Définition des métriques pour la mesure des propriétés du contour 3.3.1. Mesure de couplage Les propriétés «couplage des classes du contour» et « couplage entre les classes du contour et l’extérieur» nécessitent une mesure de couplage. Dans notre approche, nous considérons que la métrique de couplage reflète uniquement les liens d’utilisation entre deux objets. Elle doit également permettre de mesurer l’intensité du lien entre deux objets. Enfin, elle doit être relative et indépendante du langage de programmation. Malheureusement, aucune métrique disponible dans la littérature ne satisfait tous nos besoins. Nous devons donc définir notre propre métrique à partir de celle existante. Nous définissons trois métriques qui mesurent chacune un type de dépendance

Extraction de l’architecture

9

entre objets. Ces métriques sont définies comme suit, avec E un contour : – CM (E) : cette mesure est obtenue par l’adaptation de N IH − ICP (Lee et al., 1995). Ainsi CM est la mesure du nombre d’appels de méthodes depuis une classe de E vers une autre classe de E, pondéré par le nombre de paramètres de chaque méthode. On obtient une mesure relative en comparant cette valeur au nombre d’appels de méthodes depuis une classe de E vers une autre classe du système, pondéré par le nombre de paramètres de chaque méthode ; – CA(E) : adaptée à partir de DAC (Li et al., 1993), elle mesure le nombre d’attributs d’une classe de E qui ont pour type une autre classe de E. Afin d’obtenir une mesure relative, ce nombre est comparé au nombre d’attributs d’une classe de E qui ont pour type une autre classe du système ; – CP (E) : obtenue par l’adaptation de OCM IC (Briand et al., 1997), elle mesure le nombre de paramètres dans une classe de E qui ont pour type une autre classe de E. On obtient une mesure relative en comparant cette valeur au nombre de paramètres qui ont pour type une classe du système ; A partir de ces métriques, nous définissons la fonction couplage(E) qui mesure la propriété «couplage des classes du contour» : couplage(E) =

1 (CM (E) + CA(E) + CP (E)) 3

A partir de couplage(E) nous obtenons facilement la mesure du couplage entre E et le reste des classes du système (fonction couplageExt(E)). Cette fonction mesure la propriété « couplage entre les classes du contour et l’extérieur» et s’exprime de la manière suivante : couplageExt(E) = 100 − couplage(E) 3.3.2. Mesure de cohésion Les propriétés du contour «moyenne des cohésions de chaque classe de l’interface», «cohésion des classes de l’interface» et «cohésion des classes du contour» nécessitent la définition d’une mesure de cohésion. La première demande une mesure de la cohésion d’une classe alors que les deux dernières requièrent une mesure de la cohésion d’un ensemble de classes. Dans les deux cas, le calcul de la cohésion se ramène au calcul de la cohésion d’un ensemble de méthodes et d’attributs, respectivement de la classe et de l’ensemble des classes. La métrique «Loose Class Cohesion» (LCC), proposée par Bieman et Kang (Bieman et al., 1995), mesure le pourcentage de paires de méthodes connectées directement ou indirectement. On dit que deux méthodes sont connectées si elles utilisent de manière directe ou indirecte des attributs en commun. On dit que deux méthodes sont connectées indirectement s’il existe une chaîne de méthodes connectées qui les relient. Cette métrique satisfait tous nos besoins pour la mesure de la cohésion : elle reflète toutes les relations de partage d’un attribut et est un pourcentage. Par conséquent, nous utilisons cette métrique pour calculer la cohésion dans notre processus.

10

Inforsid 2007

3.4. Évaluation de la validité sémantique des composants Dans la section précédente, nous avons relié chaque caractéristique sémantique des composants à un ensemble de métriques des contours permettant de la mesurer. Nous exploitons ici ces liens pour définir des fonctions d’évaluation de chaque caractéristique puis une fonction d’évaluation de la validité sémantique des composants. 3.4.1. Fonction d’évaluation de la caractéristique de spécialisation d’un composant Nous avons établi les liens entre cette caractéristique et les propriétés des contours «moyenne des cohésions de chaque classe de l’interface», «cohésion des classes de l’interface», «cohésion des classes du contour», «couplage des classes du contour», et «nombre de classes de l’interface ayant une méthode publique». Par conséquent, elle est liée aux métriques de calcul de cohésion LCC et de couplage couplage, définies précédemment et au nombre, noté nbP ub(I), de classes de l’interface ayant une méthode publique. Ainsi, nous proposons d’évaluer cette caractéristique en utilisant la fonction suivante, où |I| est le cardinal de l’interface du contour : 1 X 1 · LCC(i) + LCC(I) + LCC(E) Spe(E) = · ( 5 |I| i∈I

+ Coupling(E) − nbP ub(I)) 3.4.2. Fonction d’évaluation de la caractéristique d’autonomie d’un composant La caractéristique d’autonomie d’un composant est liée d’après notre analyse à la propriété du contour «couplage entre les classes du contour et l’extérieur». D’où le lien avec la métrique couplageExt. Elle est mesurée de la manière suivante : A(E) = couplageExt(E) = 100 − Couplage(E) 3.4.3. Fonction d’évaluation de la caractéristique de composabilité d’un composant L’analyse précédente à permis de mettre en évidence les liens entre cette caractéristique et la propriété du contour «moyenne des cohésions de chaque classe de l’interface». Ainsi, la fonction d’évaluation de la caractéristique est la suivante : 1 X · LCC(i) C(E) = |I| i∈B

3.4.4. Fonction d’évaluation de la validité sémantique des composants L’évaluation de la validité sémantique d’un composant dépend de l’évaluation de chacune de ses caractéristiques. Pour cette raison, nous définissons cette fonction comme une combinaison linéaire de chaque fonction d’évaluation d’une caractéristique sémantique (Spe, A, et C) : 1 S(E) = P i

λi

(λ1 · C(E) + λ2 · A(E) + λ3 · Spe(E))

Extraction de l’architecture

11

Cette forme linaire de la fonction permet de considérer uniformément les différentes caractéristiques d’un composant. Par ailleurs, les différents poids attribués aux caractéristiques peuvent être choisis, par l’architecte, en fonction de l’importance donnée à chacune.

4. Processus d’identification des composants L’identification des composants, pouvant être extrait du code source objet, s’appuie sur la fonction d’évaluation des caractéristiques sémantiques des composants définie dans la section précédente. Pour réaliser ce processus, nous utilisons une approche basée sur la construction de groupes (i.e. clustering) à partir d’un ensemble initial d’éléments, en utilisant une fonction de similarité entre ces éléments. Parmi les algorithmes de clustering existants, nous avons choisi un algorithme hiérarchique pour l’identification des composants (cf. sect. 4.1). Son résultat est un arbre binaire où chaque noeud représente un cluster, les feuilles les éléments initiaux et la racine le cluster final. Nous exploitons, ensuite, cet arbre pour obtenir une partition des classes (cf. sect. 4.2).

4.1. Regroupement hiérarchique des classes objets

Figure 6. Algorithme de clustering hiérarchique Le principe de l’algorithme de clustering hiérarchique (défini par S.C.Johnson (Johnson, 1967)) est donné dans la figure 6.a. Un algorithme de «clustering» hiérarchique considère, au démarrage, que chaque élément initial constitue un cluster (ligne 4). Ensuite, à chaque étape, les deux clusters les plus similaires (fonction clusterP roche) sont regroupés dans un nouveau cluster (lignes 5 à 10). Le processus se termine lorsqu’il ne reste plus qu’un seul cluster. A

12

Inforsid 2007

partir de ce dernier cluster, on obtient une représentation en forme de dendrogramme de la hiérarchie des groupes (ligne 11). La figure 6.b présente la forme du résultat de cet algorithme. Dans cet exemple, les étapes du clustering sont (a,c), (a,c,e), puis (b,d) et enfin (a,b,c,d). Nous exploitons cet algorithme pour regrouper les classes objet du système en utilisant comme fonction de similarité notre fonction d’évaluation de la validité sémantique des composants. En effet, l’évaluation de la similarité de deux clusters consiste à appliquer la fonction d’évaluation sur le contour formé par les classes de l’union des deux clusters. Cependant, cette représentation n’est pas une partition de l’ensemble de classes. C’est pour déterminer cette partition que l’on procède à la deuxième étape.

4.2. Identification des composants à partir de la hiérarchie de clusters Pour obtenir une partition des classes du système, on doit sélectionner des noeuds dans la hiérarchie résultant de l’étape précédente. Cette sélection est réalisée par l’algorithme présenté dans la figure 7 qui sélectionne les noeuds qui représentent les contours constituant les meilleurs composants.

Figure 7. Algorithme d’identification L’algorithme de sélection des noeuds consiste en un parcours en profondeur du dendrogramme (paramètre dendro). A chaque noeud, on compare le résultat de la fonction d’évaluation S de ce noeud avec celle de ses deux fils (ligne 10). Si le résultat de la fonction d’évaluation de ce noeud est inférieur à la moyenne de ses deux fils, alors l’algorithme traite le premier fils (ligne 13, 14 et 6), sinon le noeud en question est identifié comme un contour et ajouté à la partition (variable R, ligne 11) et l’algorithme traite ensuite le noeud suivant.

Extraction de l’architecture

13

5. Étude de cas : ArgoUML

Figure 8. Résultat de l’application de l’outil ROMANTIC sur le logiciel ArgoUML Nous avons expérimenté notre processus d’extraction d’architecture sur le logiciel ArgoUML. ArgoUML est un outil de modélisation en UML développé en JAVA. Il permet de concevoir et de sauvegarder tous les diagrammes UML standard. Il fournit également un ensemble d’outils pour la génération de code à partir de ce modèle, ou encore pour obtenir le modèle à partir d’un code. ArgoUML contient 1210 classes. Nous avons identifié plus de 55000 relations d’utilisation entre ces classes. Cette complexité rend impossible l’identification manuelle des différents composants du système à moins d’avoir une connaissance très précise sur les classes du système et leur relation ou en simplifiant le processus d’identification en le basant sur des regroupements existants tel que les paquetages. L’application de notre outil ROMANTIC sur le logiciel ArgoUML donne comme résultat intermédiaire un dendrogramme dont les feuilles sont les 1210 classes d’ArgoUML. La seconde étape de notre processus permet d’extraire, depuis ce dendrogramme, treize composants. L’étude de ce résultat a montré qu’il peut être amélioré en appliquant plusieurs règles simples. Par exemple, si le graphes des classes du contour est non connexe, chaque partie connexe crée un nouveau contour.

14

Inforsid 2007

L’application de ces règles au résultat précédent, nous donne l’architecture suivante (cf. fig.8). Nous avons calculé plusieurs statistiques sur cette partition. Ainsi, nous avons mesuré le nombre de classes par composant : la moyenne est de 57 classes par composants et la valeur médiane de 7. Cette différence entre la moyenne et la médiane s’explique par la présence de cinq gros composants qui regroupent plusieurs fonctionnalités et celle de plusieurs petits composants qui possèdent une seule fonctionnalité. Nous avons mesuré également la densité de chaque composant2 : la moyenne est de 0,53 et la médiane de 0,42. Les composants ont donc tous une valeur correcte de densité et donc de couplage et de cohésion. Parmi les composants identifiés, nous avons identifié plusieurs fonctionnalités. Ainsi, les composants 1 à 9 contiennent les critiques que ArgoUML gère sur les modèles UML et les outils pour les afficher. Le composant 18 contient les classes qui permettent de générer du code JAVA à partir d’un modèle UML. Le composant 19 encapsule la fonctionnalité de disposition des différents diagrammes. Enfin, le composant 20 contient les «usines», l’implémentation et les aides de chaque diagrammes UML.

6. Travaux apparentés Différents travaux ont été proposés dans la littérature pour proposer des abstractions d’un système, en particulier pour les applications orientés objets. Nous distinguons ces travaux selon deux critères : la cible de l’abstraction et l’ensemble des éléments utilisés pour guider l’abstraction. Ainsi, par rapport à la cible d’abstraction nous distinguons essentiellement les travaux s’intéressant à l’extraction d’une vue architecturale du système et ceux s’intéressant à l’extraction d’une architecture à base de composants. Dans la première catégorie, nous pouvons citer les travaux de Kung (Kung et al., 1993), Biggerstaff (Biggerstaff, 1989), et Tzerpos (Tzerpos et al., 1996). Dans le premier travail, l’objectif est de fournir un ensemble de trois représentations qui facilitent la réalisation de test et de vérification sur le système. Ces représentations sont le diagramme de classes, des diagrammes «block Branch» qui représente chaque fonction ou méthode et enfin un ensemble de diagrammes d’états des objets. Dans le deuxième, l’objectif est de relier le code à un ensemble de représentations, telles que des flots, des diagrammes informels, etc., afin de pouvoir réutiliser ces parties de code lorsqu’on retrouve dans la conception d’un autre système la même représentation. Enfin, le dernier travail vise à extraire du code une représentation, en fonction du domaine et du système, qui facilite la compréhension du système. Par rapport à la deuxième catégorie de cible d’abstraction, nous pouvons citer principalement les travaux de Kazman (Kazman et al., 2001), Medvidovic (Medvidovic et al., April 2006) et Ivkovic (Ivkovic, 2002). Les trois travaux proposent d’abstraire une application orientée objet en une architecture à base de composants. Il est à noter que chacun propose de considérer la notion de connecteurs 2. La densité est un bon indicateur pour le couplage et la cohésion.

Extraction de l’architecture

15

lors du processus d’abstraction. Néanmoins aucun travail ne propose concrètement des mécanismes pour leur extraction. Enfin, les éléments utilisés pour guider l’abstraction permettent de distinguer les travaux proposant une approche syntaxique de ceux proposant une approche sémantique. Les approches syntaxiques telles que celles de Kung ou Kazman utilisent uniquement les informations contenues dans le code de l’application. Ainsi, les représentations que Kung propose pour faciliter les tests du système ne sont pas influencées par le domaine de l’application ou les documents de conception. A l’opposé, les travaux de Biggerstaff, Tzerpos, Medvidovic et Ivkovic proposent d’utiliser toutes les informations disponibles sur le système et son domaine d’application. Ainsi Biggerstaff et Tzerpos proposent des représentations différentes en fonction du domaine ou de l’appréciation des développeurs du système. Le premier choisit les représentations puis les met en correspondance avec le code, alors que le second réalise une première représentation dans une approche syntaxique, puis modifie cette représentation en fonction de critères sémantiques. Medvidovic et Ivkovic, par contre, conservent leur représentation sous forme d’architecture à base de composants. Cependant, ils utilisent les connaissances des concepteurs ainsi que les documents de conception pour obtenir une vue idéalisée de l’architecture (Medvidovic) ou un style d’architecture (Ivkovic). La représentation de l’architecture du système est ensuite obtenue par rapprochement entre les entités des deux vues. Concernant notre approche, la cible est une architecture à base de composants et la source est un système orienté objet. Pour les guides que nous utilisons, notre approche actuelle, utilisant uniquement les caractéristiques sémantiques, nous positionne parmi les approches syntaxiques. Cependant, l’introduction des guides utilisant les documents de conception ou les informations sur le contexte nous rapprochera des approches sémantiques.

7. Conclusion Notre objectif dans cet article est de proposer une approche permettant l’extraction de l’architecture d’un système objet. Cette approche est basée sur l’utilisation des caractéristiques sémantiques des composants. Ces caractéristiques nous permettent de guider le partitionnement des classes du système et l’identification de chaque ensemble à un composant architectural. Comme nous l’avons mentionné précédemment, les caractéristiques sémantiques que nous utilisons ne sont pas les seuls guides que l’on a identifiés pour cette approche. La première perspective de ce travail est donc l’utilisation des autres informations à notre disposition. On a ainsi débuté l’étude des qualités de l’architecture et les moyens de les mesurer sur le code objet. On envisage également d’utiliser les documents de conception (cas d’utilisation) ou encore des informations supplémentaires fournies par l’utilisateur de notre outil (par exemple recommandation sur le nombre de composants) ou par le concepteur du système (style architectural par exemple).

16

Inforsid 2007

La prise en compte des connecteurs constitue une deuxième perspective. Il nous faut étudier la sémantique des connecteurs et décider du moment de leur prise en compte : avant pendant ou après le processus d’identification.

8. Bibliographie Bertolino A., Bucchiarone A., Gnesi S., Muccini H., « An Architecture-Centric Approach for Producing Quality Systems. », QoSA/SOQUA, p. 21-37, 2005. Bieman J. M., Kang B.-K., « Cohesion and reuse in an object-oriented system », Proc. of the Symp. on Software reusability,SSR ’95, ACM Press, USA, p. 259-262, 1995. Biggerstaff T. J., « Design Recovery for Maintenance and Reuse », Computer, vol. 22, n˚ 7, p. 36-49, 1989. Briand L., Devanbu P., Melo W., « An Investigation into Coupling Measures for C++ », Proc. of the 19th Int. Conf. on Software Engineering (ICSE ’97), ACM, p. 412-421, 1997. Heinemann G., Councill W., Component-based software engineering, Addison-Wesley, 2001. ISO/IEC-9126-1Software engineering - Product quality - Part 1 : Quality Model, International Organization for Standardization and International Electrotechnical Commission, 2001. Ivkovic I., Enhancing Domain-Specific Software Architecture Recovery, PhD thesis, University of Waterloo, 2002. Johnson S., « Hierarchical clustering schemes », Psychometrika, vol. 32, p. 241-245, 1967. Kazman R., O’Brien L., Verhoef C., Architecture Reconstruction Guidelines, Technical report, 2001. Kung C. H., Gao J., Hsia P., Lin J., Toyoshima Y., « Design Recovery for Software Testing of Object-Oriented Programs », Proc. of the Working Conf. on Reverse Engineering,WCRE ’93, IEEE, p. 202-211, 1993. Lee Y., Liang B., Wu S., Wang F., « Measuring the Coupling And Cohesion of an ObjectOriented Program Based on Information Flow », ICSQ’95, p. 81-90, 1995. Li W., Henry S., « Object Oriented Metrics that Predict Maintainability », Journal of Systems and Software, vol. 223, p. 111-122, 1993. Luer C., van der Hoek A., Composition Environments for Deployable Software Components, Technical report, 2002. Medvidovic N., Jakobac V., « Using software evolution to focus architectural recovery », Automated Software Engineering, vol. 13, p. 225-256(32), April 2006. Shaw M., Garlan D., Software architecture : perspectives on an emerging discipline, PrenticeHall, USA, 1996. Szyperski C., Component Software, ISBN : 0-201-17888-5, Addison-Wesley, 1998. Tzerpos V., Holt R., « A hybrid process for recovering software architecture », Proc. of the conf. of the Centre for Advanced Studies on Collaborative Research,CASCON, p. 1-6, 1996.