Soutenance mémoire
Avantages de l’architecture
L’architecture est un point clé affectant la plupart des attributs d’un système [114]. Ces impacts ont été décrits par GARLAN et PERRY [47], du point de vue de la conception. En se plaçant du point de vue de la maintenance, nous pouvons énumérer les impacts de l’architecture selon cinq angles [74] :
• compréhension du système : l’architecture fournie une représentation d’un système à un haut niveau d’abstraction. Cette vue synthétique du système met en valeur la plupart des décisions de conception ainsi que les conséquences de ces mauvaises décisions. En effet, l’architecture met en valeur les contraintes du système qui justement intéressent les personnes réalisant la maintenance. Elle permet ainsi à ces personnes de concentrer les efforts d’exploration du système sur les informations architecturales et ainsi de comprendre plus rapidement la conception et le fonctionnement du système ;
• réutilisation : l’architecture permet facilement d’identifier les composants réutilisables d’un système. Elle permet également, à travers les connecteurs, d’identifier les dépendances existantes entre ces parties réutilisables d’un système. Au final, ces identifications rendent la réutilisation des fonctionnalités du système plus facile mais aussi plus sûre ;
• évolution : l’architecture fournie un squelette du système. Ce squelette permet d’identifier les parties fortement utilisées ainsi que les parties potentiellement fragiles. L’architecture permet ainsi de mettre en valeur les parties nécessitant une attention particulière lors de l’évolution du système. Mais l’architecture permet également de révéler une image précise des dépendances entre les composants. Cette image est nécessaire pour connaitre les impacts de la modification d’un composant sur les autres composants du système et donc les conséquences des différentes évolutions. Elle permet aussi de modifier ces dépendances pour améliorer certains attributs du système tels que la performance ou l’interopérabilité. Enfin, l’architecture permet de corriger les erreurs à la source plutôt que là où elles apparaissent. Ceci peut être réalisé en localisant le composant fautif ou encore certaines dépendances ou contraintes non documentées ;
• analyse : la vue abstraite fournie par l’architecture permet de mesurer différents attributs tels que la consistance du système, son respect du style architectural ou encore d’autres attributs de qualité. Elle permet également de vérifier que les changements prévus dans le système sont conformes au style et aux objectifs de qualité fixés à la conception ;
• gestion de projet : la gestion des projets de maintenance du système peuvent reposer sur les composants du système. De plus, l’architecture permet une gestion plus précise des coûts et des risques de modifications, en particulier en soulignant les dépendances entre les composants. Elle permet également une évaluation des qualités du système dans son ensemble, mais aussi des qualités de chaque composant. Ceci permet d’identifier les parties les plus faibles du système et ainsi d’examiner et de cibler précisément leurs faiblesses. Cette identification des composants les plus faibles permet de mettre en valeur les composants les plus problématiques et de décider de leur réingénierie ou de leur redéveloppement. Enfin, la connaissance de la valeur de chaque composant et de leurs dépendances permet de planifier la réingénierie d’un système complexe en ordonnant les modifications selon leurs impacts sur la qualité du logiciel et le risque qu’elles soulèvent.
Les différentes facettes des architectures logicielles
La terminologie que nous avons présentée est le résultat d’une évolution progressive, portant principalement sur la réification des composants, c’est-à-dire l’entité logicielle correspondant au composant architectural dans le code de l’application, et sur l’intérêt porté aux connecteurs. La raison principale de cette évolution est que cette terminologie est le résultat du rapprochement des travaux portant sur l’architecture logicielle dans différentes communautés scientifiques. Chacune de ces communautés s’est donc forgée une vue différente de l’architecture en fonction de ces préoccupations et de son historique. La terminologie commune a ensuite émergé progressivement au gré des rapprochements entre les communautés. De plus, l’architecture étant intimement liée au système et à son paradigme de programmation, l’évolution de la terminologie a aussi été marquée par les fluctuations des paradigmes utilisés par l’ingénierie pour organiser les grands systèmes.
Fluctuation des définitions de l’architecture La définition de l’architecture est soumise à des variations en fonction du contexte des travaux qui l’utilisent ou la produisent. A ce titre, les paradigmes de programmation jouent un rôle prépondérant dans les variations de la définition d’architecture. En effet, les entités appartenant à chaque paradigme sont identifiées aux éléments architecturaux. Cette identification impose une sémantique et une représentation à l’élément architectural qui découle plus du paradigme que de la définition de l’architecture. Or, le paradigme idéal à utiliser pour organiser un système a beaucoup fluctué au cours de l’histoire de l’informatique. Selon le modèle de RACOON [104] (cf. Figure 1.6), différents paradigmes ont successivement été jugés comme le meilleur. Par conséquent, ces fluctuations des paradigmes de l’ingénierie ont entrainé des variations de la notion d’architecture. Ainsi les paradigmes procédural, objet et composants ont entrainé l’apparition de cinq variations dans la définition de l’architecture et, en particulier, de celle des composants architecturaux [42]. Architectures et modules. La notion de module a beaucoup évolué, en même temps que les technologies. Ainsi YOURDON et CONSTANTIN [135] définissent un module comme une séquence continue d’instructions, bornée par des éléments frontières et possédant un identifiant. Cette définition est cependant plus proche de l’image que nous avons d’une fonction. Dans les langages plus récents, un module est une unité syntaxique contenant des fonctions, des sous-programmes et des déclarations de types et supportant l’encapsulation. Les entités du module sont accessibles aux autres modules à travers son interface, alors que l’implémentation est cachée. Cette définition des modules fait apparaitre de nombreux parallèles avec celle des composants : encapsulation et interface principalement. Ainsi, par identification, l’implémentation d’une architecture consiste à créer un module pour chaque composant architectural. A l’opposé, l’identification de l’architecture d’un système est réalisée en identifiant les modules du système [4, 123]. Architectures et sous-systèmes. L’identification entre les composants de l’architecture et les soussystèmes d’un logiciel, résulte de l’introduction de la notion de hiérarchie au sein des composants architecturaux. Ainsi, un sous-système est un regroupement de modules ou de sous-systèmes de granularité plus faible. La différence fondamentale avec la vue modulaire est la granularité. Malgré cette différence de granularité et cette hiérarchie, l’objectif des travaux d’extraction et de maintenance identifiant soussystèmes et composants [74], reste d’obtenir des composants entretenant un faible couplage et présentant une forte cohésion. Architectures et objets. L’émergence du paradigme objet a conduit au développement de la notion d’architecture objet. Dans cette architecture, les composants représentent les classes du système. L’architecture permet de représenter un système procédural selon les concepts objets. Chaque composant est un regroupement de fonctions, sous-programmes, variables et de déclarations de types qui forment un objet [110]. La différence majeure avec les définitions précédentes, en plus de l’introduction de la notion d’objet, est encore une fois la granularité des composants. Les classes peuvent être regroupées dans un module. Patrons de conception. Comme pour les objets, l’émergence de la notion de patron de conception a provoqué l’émergence d’une nouvelle définition de l’architecture. Les patrons de conception représentent les bonnes pratiques de conception et de maintenance dans le paradigme objet. Une architecture basée sur ces éléments est utilisée pour représenter des systèmes orientés objet en termes de patrons de conception et d’interactions entre ces patrons. Les architectures à base de patrons permettent de vérifier facilement la qualité de conception d’un système mais aussi d’identifier rapidement les problèmes majeurs de l’application et enfin de proposer des solutions à ces problèmes [57]. Architectures et composants logiciels. De la même manière que pour l’architecture objet ou patron, le développement de la technologie des composants logiciels a eu lieu en parallèle avec le développement des architectures à base de composants logiciels. Les composants et connecteurs architecturaux représentent alors respectivement les composants logiciels et les connecteurs. Les architectures à base de composants sont couramment utilisées pour la maintenance et l’évolution des systèmes orientés objet. Comparaison des vues architecturales Au delà de la différence dans la définition associée aux composants, ces définitions d’architectures ont une granularité différente. Ainsi, nous pouvons établir un ordre partiel entre les composants de ces architectures suivant leurs granularités (cf. Figure 1.7). D’abord, la plus fine granularité concerne les objets. Ensuite, les granularités des approches composants, patrons de conception et modules sont incomparables. Enfin, la granularité des modules est plus fine que celle des sous-systèmes. Un autre point de comparaison entre ces définitions est le paradigme sur lequel la définition a été appliquée (cf. Figure1.8). En effet, les définitions à base de modules et de sous-systèmes ont été utilisées principalement dans le cadre du paradigme procédural. Au contraire, les définitions à base de composants et de patrons de conception proviennent principalement d’approches reposant sur le paradigme objet. Enfin, la définition reposant sur les objets est utilisée pour ces deux paradigmes. Cette définition a donc un statut particulier puisqu’elle établit un lien entre les deux paradigmes et, de ce fait, entre les différentes définitions de l’architecture.
Définitions communautaires de l’architecture Comme nous l’avons vu, la définition de l’architecture varie en parallèle avec les paradigmes de programmation. Cependant, ce facteur n’est pas la seule source des variations dans la définition de la notion d’architecture. Une autre cause majeure de cette hétérogénéité est l’utilisation de l’architecture dans différentes communautés scientifiques puisque leurs définitions de l’architecture sont directement issues de leurs préoccupations et de leurs historiques [42]. Au final, les communautés possèdent chacune une définition propre de l’architecture. Les intérêts portés aux éléments architecturaux varient également d’une communauté à l’autre, de la même manière que l’utilisation qui est faite de l’architecture. Les principales communauté utilisant l’architecture sont : la communauté « objet », la communauté « Langage de Description d’Architecture » (Architecture Description Langage, ADL), la communauté « réingénierie » et enfin la communauté « d’ingénierie logicielle à base de composants » (Componentbased Software Engineering, CBSE). Architectures et communauté ADL. Cette communauté propose un ensemble de langages plus ou moins formels pour décrire une architecture logicielle. A ce titre, la définition et l’étude de la notion d’architecture sont le sujet principal des travaux. L’objectif de ces langages de description est de décrire directement les entités architecturales sans utiliser de notions issues d’un autre paradigme. La notion de connecteur bénéficie d’une attention particulière dans cette communauté par rapport aux autres. En effet, c’est dans les travaux de cette communauté que la parité entre les composants et les connecteurs est la plus établie. Cependant, le traitement accordé aux connecteurs dans cette communauté reste très hétérogène. Ainsi, certains langages de description proposent un seul type de connecteurs simples [3] alors que d’autres permettent de définir des connecteurs atomiques [2, 46]. Architectures et communauté CBSE. La communauté d’ingénierie logicielle à base composants vise à assembler des applications en utilisant des composants logiciels. Ces composants sont une notion très proche des composants architecturaux. Ainsi, les architectures sont ici exprimées en termes de composants logiciels. Par contre, les connecteurs sont encore souvent considérés comme des entités de second plan, se résumant alors à un simple appel de méthode. Cette situation tend, cependant, à s’atténuer suite aux rapprochements avec la communauté ADL. Architectures et communauté objet. La structuration de grands systèmes orientés objet est un problème ouvert. La communauté est parvenue à la conclusion que les notions de classes et d’objets sont insuffisantes pour résoudre ce problème. Par conséquence, l’architecture d’un système est souvent, dans ce domaine, exprimée en termes de patrons de conception. Comme pour la communauté CBSE, les connecteurs constituent des éléments secondaires dans l’architecture. Ils représentent des appels de méthodes ou des relations de dépendances entre les patrons de conception. Architectures et communauté réingénierie. Cette communauté a également exprimé de plusieurs façons la notion d’architecture d’un système. Pendant la période d’intérêt pour les modules, les travaux de cette communauté portaient principalement sur l’expression de l’architecture à travers la notion de module. Par la suite, l’apparition et le développement des objets ont conduit les travaux de cette communauté vers des architectures exprimées en objets. Enfin, l’émergence du développement à base de composants à mis en lumière l’utilisation des composants logiciels pour structurer l’architecture.
Classification des approches de mesure de la qualité logicielle
La vue abstraite fournie par l’architecture permet la mesure de différents attributs. Ces attributs reflètent la qualité du système représenté par l’architecture. Tirant partie de cet avantage, de nombreux travaux visent à utiliser l’architecture pour mesurer la qualité des systèmes. Ces travaux de mesure de la qualité logicielle (Software Quality Measurement, SQM) peuvent être classés selon cinq axes (cf. Figure 1.9) :
• les objectifs de l’approche : la mesure de la qualité d’une architecture peut avoir plusieurs objectifs selon que cette évaluation est réalisée de manière préventive (prédiction), ou corrective/validante (mesure). L’évaluation peut également viser différentes caractéristiques de qualité ;
• le modèle de qualité : il détermine la façon dont chaque caractéristique est mesurée. Certaines approches suivent des modèles de mesure établis et clairement définis. D’autres, mesurant une seule caractéristique de qualité, n’adhèrent à aucun modèle ;
• les entrées de l’approche : le processus d’évaluation peut prendre différents artefacts en entrée. Les approches utilisent toute l’architecture, mais certaines utilisent également la modélisation UML ou le code pour représenter le système. Elles utilisent également un ensemble de valeurs obtenues par test du logiciel, lorsque celui existe déjà, ou par approximation ;
• la technique de l’approche : le processus d’évaluation peut être reproductible ou non. Les processus reproductibles utilisent des métriques ou une modélisation du système pour évaluer la qualité d’un logiciel. Chaque exécution du processus sur un système particulier produit un résultat similaire. Les processus non reproductibles sont en grande partie manuels. Ils utilisent des groupes d’experts pour créer des scénarios et évaluer le système en fonction de ces scénarios ;
• les sorties de l’approche : toutes les approches visent à évaluer la qualité de l’architecture ou du système étudié. Cependant, certaines fournissent une valeur pour cette caractéristique alors que d’autres déterminent la meilleure solution selon un aspect précis. Enfin, certaines utilisent cette évaluation pour orienter un processus de maintenance. Dans la suite de cette section, nous étudions successivement chaque axe de cette classification.
Conséquence de l’absence de représentation architecturale
Les avantages de l’architecture pendant les phases de maintenance, ont rendu cette abstraction cruciale pour diriger les opérations correctives ou d’amélioration des systèmes. De nombreuses approches de maintenance reposent en grande partie sur la représentation architecturale pour visualiser le système. Ainsi, une architecture, décalée par rapport à la réalité du système, fournit une image fausse de ce système. Cette erreur, introduite des le début du processus de maintenance, peut conduire à deux types de conséquences. Les premières conséquences sont des erreurs de non-détection. Si on tente de détecter des erreurs dans un système, la non-représentation de certaines relations dans l’architecture, risque de cacher certaines erreurs ou mauvaises utilisations d’un patron de conception. Dans le cas d’une phase de maintenance visant à introduire une modification dans le système, le masquage de certaines dépendances peut entrainer des effets de bords inattendus ou encore un échec de la modification du système. Le deuxième type d’erreurs concerne les faux positifs. Dans les phases de maintenance corrective, les dépendances ajoutées dans l’architecture peuvent entrainer la détection d’erreurs qui n’existent pas dans le système. Dans ce cas, la correction de ces erreurs risquent de dégrader le système. Dans le cas d’une phase de maintenance visant à introduire une modification dans le système, les dépendances supplémentaires peuvent provoquer des modifications dans une partie du système indépendante et entrainer des dégradations dans cette partie. Une incohérence entre l’architecture et le système représenté (masquage ou ajout de relations), peut, à tout moment, provoquer des conséquences imprévues durant la maintenance. Ces conséquences peuvent aller de l’échec de la maintenance à la dégradation du système. Au final, il est pratiquement impossible de réaliser des évolutions sur un système en s’appuyant sur une architecture qui ne correspond pas précisément à l’architecture réelle du système. Or, il est impossible d’avoir la garantie que le processus de développement, puis de maintenance, ont conservé une synchronisation parfaite entre ces deux architectures. Pour résoudre ce manque et pouvoir bénéficier de toutes les approches d’évolution disponibles ainsi que de tous les avantages de l’architecture, de nombreuses approches proposent d’extraire une représentation de l’architecture réelle d’un système.
|
Table des matières
Introduction
Partie I — Contexte et travaux connexes
1 Architectures logicielles
1.1 Concepts et terminologie des architectures logicielles
1.1.1 Les composants
1.1.1.1 Structure externe d’un composant
1.1.1.2 Structure interne d’un composant
1.1.1.3 Relations de compositions des composants
1.1.2 Les connecteurs
1.1.2.1 Aspect Fonctionnel du connecteur
1.1.2.2 Structure externe du connecteur
1.1.2.3 Structure interne du connecteur
1.1.3 La configuration
1.1.3.1 Structure de la configuration
1.1.3.2 Les propriétés de la configuration
1.1.4 Le style architectural
1.1.4.1 Style et interprétation de l’architecture
1.1.4.2 Style et réalisation de l’architecture
1.1.5 Avantages de l’architecture
1.2 Les différentes facettes des architectures logicielles
1.2.1 Fluctuation des définitions de l’architecture
1.2.2 Définitions communautaires de l’architecture
1.3 Architectures logicielles et mesure de la qualité logicielle
1.3.1 Classification des approches de mesure de la qualité logicielle
1.3.2 Les objectifs de l’approche
1.3.3 Le modèle de qualité
1.3.4 Les entrées de l’approche
1.3.5 La technique de l’approche
1.3.6 Les sorties de l’approche
1.4 Conclusion
2 Extraction d’architectures logicielles
2.1 Une architecture cruciale mais pas toujours disponible
2.1.1 Maintenance et architecture
2.1.2 Le manque de représentations architecturales fiables
2.1.2.1 Représentation architecturale indisponible
2.1.2.2 Représentation architecturale décalée
2.1.3 Conséquence de l’absence de représentation architecturale
2.2 Principes de l’extraction d’architectures
2.2.1 Définition de l’extraction d’architectures
2.2.2 Modèles conceptuels existants de l’extraction d’architectures
2.2.2.1 Modèle en fer à cheval de l’extraction d’architectures
2.2.2.2 Modèle conceptuel de l’extraction d’architectures
2.2.2.3 Limites des modèles existants
2.2.3 Notre modèle conceptuel de l’extraction d’architectures
2.3 Comparaison des approches d’extraction d’architectures
2.3.1 Cadre de comparaison des approches d’extraction d’architectures
2.3.2 Axe des propriétés conceptuelles
2.3.2.1 Niveau du code source
2.3.2.2 Niveau du modèle du code source
2.3.2.3 Niveau de mise en correspondance
2.3.2.4 Niveau de l’architecture
2.3.2.5 Enchainements des niveaux
2.3.3 Axe des informations utilisées
2.3.3.1 Intervention de l’utilisateur
2.3.3.2 Utilisation de la documentation
2.3.4 Axe des propriétés techniques
2.3.4.1 Critères de regroupement
2.3.4.2 Algorithmes
2.3.4.3 Degré d’automatisation
2.3.4.4 Les modes d’utilisation
2.4 Conclusion
Partie II — La démarche ROMANTIC pour l’extraction d’architectures
3 Problématique et approche de ROMANTIC
3.1 Motivation et problème
3.1.1 Extraction d’architectures
3.1.1.1 Propriétés conceptuelles
3.1.1.2 Informations utilisées
3.1.1.3 Propriétés techniques
3.1.2 Approches par exploration
3.2 Présentation de notre solution : ROMANTIC
3.2.1 Propriétés conceptuelles dans ROMANTIC
3.2.1.1 Niveau du code source et du modèle du code source
3.2.1.2 Niveau de l’architecture
3.2.1.3 Niveau de correspondance
3.2.2 Informations utilisées dans ROMANTIC
3.2.3 Propriétés techniques de ROMANTIC
3.3 Modélisation du problème
3.3.1 Notre modèle du code source
3.3.1.1 Le modèle FAMIX
3.3.1.2 Spécialisation de FAMIX pour l’extraction d’architectures
3.3.2 Notre modèle de mise en correspondance
3.3.3 Notre approche par exploration
3.3.3.1 L’espace des solutions
3.3.3.2 L’espace de recherche
3.3.3.3 L’exploration
3.4 Guides du processus d’extraction d’architectures
3.4.1 Guides pour l’identification de l’objectif
3.4.1.1 Sémantique architecturale
3.4.1.2 Qualité architecturale
3.4.2 Guides pour la réduction de l’espace de recherche
3.4.2.1 Documentation et recommandations
3.4.2.2 Contexte de déploiement
3.5 Conclusion
4 Fondement du processus d’extraction
4.1 Méta-modèle de mesure
4.1.1 Méta-modèle de mesure de la norme ISO-9126
4.1.2 Méta-modèle de mesure dans ROMANTIC
4.2 Étude de la sémantique architecturale
4.2.1 Caractéristiques sémantiques de l’architecture
4.2.1.1 Caractéristiques sémantiques des composants
4.2.1.2 Caractéristiques sémantiques des connecteurs
4.2.2 Des caractéristiques sémantiques aux propriétés architecturales
4.2.2.1 Les propriétés des composants
4.2.2.2 Les liens entre les caractéristiques et les propriétés des composants
4.2.2.3 Les propriétés des connecteurs
4.2.2.4 Les liens entre les caractéristiques et les propriétés des connecteurs
4.2.3 Des propriétés architecturales aux propriétés des entités COA
4.2.3.1 Liens entre les propriétés internes des éléments architecturaux et des entités COA
4.2.3.2 Liens entre les propriétés de l’enveloppe des éléments architecturaux et des entités COA
4.2.4 Des propriétés du modèle COA au modèle objet
4.2.4.1 Liens entre les interfaces verticales et les entités COA
4.2.4.2 Mesure de couplage
4.2.4.3 Mesure de cohésion
4.3 Etude de la qualité architecturale
4.3.1 Caractéristiques de qualité
4.3.1.1 Les caractéristiques de qualité de la norme ISO-9126
4.3.1.2 Les caractéristiques de qualité de notre modèle de mesure
4.3.2 Des caractéristiques de qualité aux propriétés architecturales
4.3.2.1 Maintenabilité de l’architecture
4.3.2.2 Fiabilité de l’architecture
4.3.3 Des propriétés architecturales aux propriétés des entités COA
4.3.3.1 Propriétés de la maintenabilité
4.3.3.2 Propriétés de la fiabilité
4.3.4 Des propriétés COA aux métriques objets
4.3.4.1 Maintenabilité des modules objets
4.3.4.2 Complexité des modules objets
4.4 Définition de la fonction objectif
4.4.1 Mesure de la validité sémantique de l’architecture
4.4.1.1 Evaluation de la validité sémantique des composants
4.4.1.2 Evaluation de la validité sémantique des connecteurs
4.4.1.3 Evaluation de la validité sémantique de l’architecture
4.4.2 Mesure de la qualité architecturale
4.4.2.1 Mesure de la maintenabilité de l’architecture
4.4.2.2 Mesure de la fiabilité de l’architecture
4.4.2.3 Mesure de la qualité architecturale
4.4.3 Fonction objectif du processus d’exploration
4.5 Conclusion
5 Guider le processus d’extraction
5.1 Les guides de l’extraction
5.1.1 Les informations intentionnelles
5.1.2 Les informations contextuelles
5.1.3 Influence des guides sur l’exploration
5.1.4 Modélisations des informations intentionnelles et contextuelles
5.1.4.1 Modèle pour le ciblage
5.1.4.2 Modèle pour la suppression
5.2 Extraction d’architectures intentionnelles depuis la documentation
5.2.1 Processus de partitionnement
5.2.1.1 Étape de regroupement
5.2.1.2 Étape de partitionnement
5.2.1.3 Processus de validation des informations
5.2.2 Mesure de similarité dans la documentation
5.2.2.1 La similarité dans les diagrammes UML
5.2.2.2 La similarité dans les fichiers sources
5.2.2.3 La similarité dans les archives des outils de versionnement
5.3 Création d’un réseau de contrainte hiérarchique
5.3.1 Les recommandations de l’architecte
5.3.1.1 Informations contextuelles
5.3.1.2 Informations intentionnelles
5.3.1.3 Collecte des recommandations
5.3.2 Les contraintes issues des architectures intentionnelles
5.3.3 Combinaison des contraintes
5.4 Conclusion
Partie III — Mise en pratique et validation de ROMANTIC
6 Algorithmes pour l’exploration
6.1 Algorithmes d’exploration pour ROMANTIC
6.2 Instance de ROMANTIC à base de regroupement hiérarchique
6.2.1 Extraction d’architectures simplifiées
6.2.1.1 Heuristiques pour le calcul de la fonction objectif
6.2.1.2 Algorithme de regroupement hiérarchique
6.2.1.3 Algorithme d’identification des composants à partir du dendrogramme
6.2.2 Extraction d’architectures logicielles
6.2.2.1 Identification des interfaces
6.2.2.2 Identification des connecteurs
6.2.2.3 Identification de la configuration
6.2.2.4 Identifications des composites
6.2.2.5 Utilisation des méthodes de réductions de l’espace de recherche
6.2.3 Analyse du processus par regroupement hiérarchique
6.2.3.1 Complexité des algorithmes
6.2.3.2 Avantages et inconvénients
6.3 Instance de ROMANTIC à base de recuit simulé
6.3.1 Algorithme d’extraction
6.3.1.1 Principes de l’algorithme de recuit simulé
6.3.1.2 Schéma de refroidissement
6.3.1.3 Réduction de l’espace de recherche
6.3.2 Définition du voisinage
6.3.2.1 Opérateurs de manipulation
6.3.2.2 Choix des opérations de manipulations
6.3.3 Point de départ de l’exploration
6.3.3.1 Utilisation des guides de l’approche
6.3.3.2 Utilisation d’heuristiques
6.3.4 Analyse du processus par recuit simulé
6.4 Instance de ROMANTIC à base d’algorithmes génétiques
6.4.1 Présentation des algorithmes génétiques
6.4.2 Codage de l’architecture
6.4.2.1 Chromosome des composants
6.4.2.2 Chromosome des connecteurs
6.4.2.3 Chromosome de la configuration
6.4.3 Définitions des opérateurs génétiques
6.4.3.1 Opérateurs de sélection
6.4.3.2 Opérateurs de croisement
6.4.3.3 Opérateurs de mutations
6.4.4 Choix de la population initiale
6.4.4.1 Individus basés sur les guides de l’extraction
6.4.4.2 Individus basés sur les autres approches par exploration
6.4.5 Analyse du processus par algorithme génétique
6.5 Conclusion
7 Validation et évaluation de l’approche ROMANTIC
7.1 Cadre du cas d’étude
7.1.1 Instances de ROMANTIC
7.1.1.1 Paramétrage des algorithmes
7.1.1.2 Utilisation des guides
7.1.2 Systèmes étudiés
7.1.2.1 Jigsaw
7.1.2.2 ArgoUML
7.2 Validation des fondements théoriques
7.2.1 Méthode de validation des fondements théoriques
7.2.1.1 Consistance de ROMANTIC
7.2.1.2 Adéquation de ROMANTIC
7.2.2 Analyse des résultats
7.2.2.1 Étude de la consistance de notre approche
7.2.2.2 Étude de l’adéquation de notre approche
7.2.3 Conclusion sur la validité de ROMANTIC
7.3 Comparaison des instances de ROMANTIC
7.3.1 Méthode de comparaison des algorithmes
7.3.1.1 Efficacité d’un algorithme
7.3.1.2 Comparaison des algorithmes
7.3.2 Comparaison des algorithmes
7.3.2.1 Étude de la vitesse des algorithmes
7.3.2.2 Étude du rapport entre vitesse et précision des algorithmes
7.3.2.3 Conclusion sur le choix des algorithmes
7.4 Conclusion
Partie IV — Conclusion et perspectives
Conclusion
Télécharger le rapport complet
