3.3 L’évaluation des approches selon notre modèle de qualité
3.3.7 L’évaluation de l’approche de Mahdavi et al. selon notre modèle de qualité 60
Mahdavi et al. [Mahdavi et al., 2003a,Mahdavi et al., 2003b] ont proposé un processus d’extrac-tion pour obtenir une décomposid’extrac-tion du système (qui est une architecture) ayant un couplage faible entre les éléments et une cohésion forte entre les entités d’un même élément. Le pro-cessus, supporté par les extracteurs des graphes MDG et l’outil Bunch, se focalise sur l’idée de groupement plusieurs fois, tout en prenant en compte certains informations de la part de l’architecte. En effet, l’idée de Mahdavi et al. consiste à élaborer desBuilding Blocks. Ces enti-tés logicielles sont des groupes d’entienti-tés obtenus après une exécution multiple de l’algorithme Hill Climbing. Ainsi, l’architecte choisit ces Building Blocks tout en comparant les résultats des exécutions. Par la suite, nous pouvons dire que l’architecte interagit et intègre ses connais-sances avec un faible degré dans le processus d’extraction. La table3.7résume l’évaluation de l’approche de Mahdavi et al. selon notre modèle de qualité.
3.3. L’ÉVALUATION DES APPROCHES SELON NOTRE MODÈLE DE QUALITÉ 61 TABLE3.6 : L’évaluation de l’approche de Mancoridis et al. selon notre modèle de qualité.
Facteur Critère Métrique Q
Méta-modèle - -
-Méthode
Intégration des connaissances
de l’architecte Pas d’intégration des connaissances
de l’architecte MV
Interaction de l’architecte Pas d’interaction de l’architecte MV
Types des informations Différents types B
Groupement des entités
logi-cielles Groupement plusieurs fois B
Correspondance des entités logicielles à l’architecture
conceptuelle Pas de correspondance MV
Identification d’une architec-ture logicielle complète
une architecture logicielle en termes d’éléments architecturaux et les éléments qui les composent MY
Outil
Intégration des connaissances
de l’architecte Ne supporte pas l’intégration des connaissances de l’architecte MV Interaction de l’architecte Ne supporte pas l’interaction de
l’architecte MV
Structure extraite Structure statique MY
Représentation des
informa-tions Pas selon un modèle ou standard MY
Langages de programmation
supportés Plusieurs langages de
programma-tion B
Types de programmation
sup-portés Plusieurs types de programmation B
Groupement des entités
logi-cielles Supporte plusieurs groupement des
entités logicielles B
Correspondance des entités logicielles à l’architecture
conceptuelle Ne supporte pas la correspondance MV
3.3.8 L’évaluation de l’approche de Rajalakshmi selon notre modèle de qualité
Rajalakshmi [Rajalakshmi, M, 2014] a proposé un processus d’extraction pour obtenir une dé-composition du système ayant un couplage faible entre les éléments et une cohésion forte entre les entités d’un même élément tout en prenant en compte l’avis de l’architecte. La table3.8 ré-sume la projection des travaux de Mahdavi selon notre modèle de comparaison. Son processus se focalise sur l’exécution du processus de groupement plusieurs fois mais en ajoutant à chaque fois des contraintes données par l’architecte. Ainsi, la méthode d’extraction de Rajalakshmi est basée sur l’interaction de l’architecte après chaque groupement dans le but de raffiner les résultats des groupements.
Comme Mahdavi, Rajalakshmi a proposé d’utiliser un outil pour extraire un graphe MDG représentant les modules et leurs relations et l’outil Bunch pour grouper les entités logicielles.
TABLE3.7 : L’évaluation de l’approche de Mahdavi et al. selon notre modèle de qualité.
Facteur Critère Métrique Q
Méta-modèle - -
-Méthode
Intégration des connaissances
de l’architecte Intégration moyenne, en choisissant
lesBuilding Blocks MY
Interaction de l’architecte Interaction moyenne, en choisissant
lesBuilding Blocks MY
Types des informations Différents types B
Groupement des entités
logi-cielles Groupement plusieurs fois B
Correspondance des entités logicielles à l’architecture
conceptuelle Pas de correspondance MV
Identification d’une architec-ture logicielle complète
Une architecture logicielle en termes d’éléments architecturaux et les éléments qui les composent MY
Outil
Intégration des connaissances
de l’architecte Ne permet pas l’intégration des connaissances de l’architecte MV Interaction de l’architecte Ne permet pas l’interaction de
l’ar-chitecte MV
Structure extraite Structure statique MY
Représentation des
informa-tions Pas selon un modèle ou standard MY
Langages de programmation
supportés Plusieurs langages de
programma-tion B
Types de programmation
sup-portés Plusieurs types de programmation B
Groupement des entités
logi-cielles Supporte plusieurs groupement des
entités logicielles B
Correspondance des entités logicielles à l’architecture
conceptuelle Ne supporte pas la correspondance MV
3.3.9 L’évaluation de l’approche de Bowman et al. selon notre modèle de qualité
Bowman et al. [Bowman et al., 1999] ont proposé une méthode d’extraction qui est quasi-manuelle. La table3.9 résume la projection des travaux de Bowman et al. selon notre modèle de comparaison. Cette approche, qui vise à extraire l’architecture du système Linux, repose sur la correspondance (d’une manière manuelle) des fichiers du système Linux à une architecture conceptuelle proposée par l’architecte. Ainsi, l’architecte intègre ses connaissances et interagit avec le processus tout en proposant une architecture conceptuelle, en faisant la mise en corres-pondance et en raffinant les résultats. Le résultat final est en termes des éléments architecturaux et les éléments (les fichiers) qui les composent.
Concernant un outil qui supporte le processus d’extraction, Bowman et al. proposent d’uti-liser (1) l’outil cfx pour extraire les fonctions et leurs appels, et (2) l’outil grok pour extraire les relations entre les fichiers selon les appels des fonctions.
3.3. L’ÉVALUATION DES APPROCHES SELON NOTRE MODÈLE DE QUALITÉ 63 TABLE3.8 : L’évaluation de l’approche de Rajalakshmi selon notre modèle de qualité.
Facteur Critère Métrique Q
Méta-modèle - -
-Méthode
Intégration des connaissances
de l’architecte Intégration moyenne, en suivant les
deux stratégies MY
Interaction de l’architecte Permet seulement le raffinement
des artefacts MY
Types des informations Différents types B
Groupement des entités
logi-cielles Groupement plusieurs fois B
Correspondance des entités logicielles à l’architecture
conceptuelle Pas de correspondance MV
Identification d’une architec-ture logicielle complète
une architecture logicielle en termes d’éléments architecturaux et les éléments qui les composent MY
Outil
Intégration des connaissances
de l’architecte Ne permet pas l’intégration des connaissances de l’architecte MV Interaction de l’architecte Ne permet pas l’interaction de
l’ar-chitecte MV
Structure extraite Structure statique MY
Représentation des
informa-tions Pas selon un modèle ou standard MY
Langages de programmation
supportés Plusieurs langages de
programma-tion B
Types de programmation
sup-portés Plusieurs types de programmation B
Groupement des entités
logi-cielles Supporte plusieurs groupement des
entités logicielles B
Correspondance des entités logicielles à l’architecture
conceptuelle Ne supporte pas la correspondance MV
3.3.10 L’évaluation de l’approche ARM selon notre modèle de qualité
Guo et al. [Guo et al., 1999] ont proposé la méthode d’extraction ARM basée sur l’outil Dali pour reconstruire l’architecture du système en termes de patrons(design pattern). La table3.10 résume la projection des travaux de Guo selon notre modèle de comparaison. La méthode in-tègre les connaissances de l’architecte dans le processus en lui permettant de proposer une architecture conceptuelle. De même, elle lui permet de raffiner cette architecture et le résultat obtenu en modifiant l’architecture conceptuelle saisie sous forme de requêtes. Concernant les types des informations, les types sont les fichiers, les classes et fonctions avec les relations entre eux. Le résultat final est en termes des éléments architecturaux (qui respectent un patron) et les éléments qui les composent.
TABLE3.9 : L’évaluation de l’approche de Bowman et al. selon notre modèle de qualité.
Facteur Critère Métrique Q
Méta-modèle - -
-Méthode
Intégration des connaissances de l’architecte
Proposition d’une architecture conceptuelle et d’autres
informa-tions B
Interaction de l’architecte Seulement raffienemt des artefacts MY Types des informations pas trop significatives (fichiers
phy-siques) MV
Groupement des entités
logi-cielles Pas de groupement des entités
logi-cielles MV
Correspondance des entités logicielles à l’architecture conceptuelle
Correspondance avec identification
de la méthode B
Identification d’une architec-ture logicielle complète
une architecture logicielle en termes d’éléments architecturaux et les éléments qui les composent MY
Outil
Intégration des connaissances
de l’architecte Ne permet pas l’intégration des connaissances de l’architecte MV Interaction de l’architecte Ne permet pas l’interaction de
l’ar-chitecte MV
Structure extraite Structure statique MY
Représentation des
informa-tions Pas selon un modèle ou standard MY
Langages de programmation
supportés un seul langage de programmation MY
Types de programmation
sup-portés Plusieurs types de programmation B
Groupement des entités
logi-cielles Ne supporte pas le groupement des
entités logicielles MV
Correspondance des entités logicielles à l’architecture
conceptuelle Ne supporte pas la correspondance MV
3.3. L’ÉVALUATION DES APPROCHES SELON NOTRE MODÈLE DE QUALITÉ 65 TABLE3.10 : L’évaluation de l’approche ARM selon notre modèle de qualité.
Facteur Critère Métrique Q
Méta-modèle - -
-Méthode
Intégration des connaissances
de l’architecte Seulement proposition d’une
archi-tecture conceptuelle MY
Interaction de l’architecte Seulement raffinement des artefacts MV
Types des informations signification moyenne MY
Groupement des entités
logi-cielles Pas de groupement des entités
logi-cielles MV
Correspondance des entités logicielles à l’architecture conceptuelle
Correspondance avec identification
de la méthode B
Identification d’une architec-ture logicielle complète
une architecture logicielle en termes d’éléments architecturaux et les éléments qui les composent MY
Outil
Intégration des connaissances
de l’architecte Seulement proposition d’une
archi-tecture conceptuelle MY
Interaction de l’architecte Supporte le raffinement des
arte-facts MY
Structure extraite Structure statique MY
Représentation des
informa-tions Pas selon un modèle ou standard MY
Langages de programmation
supportés Plusieurs langages de
programma-tion B
Types de programmation
sup-portés Plusieurs types de programmation B
Groupement des entités
logi-cielles Ne supporte pas le groupement des
entités logicielles MV
Correspondance des entités logicielles à l’architecture
conceptuelle Supporte la correspondance B