Problématique et approche de
3.4 Guides du processus d’extraction d’architectures
Pour explorer l’espace des solutions, notre processus nécessite des éléments permettant de le guider parmi l’ensemble des architectures possibles. Nous avons identifié plusieurs guides (cf. Figure 3.16) permettant de diriger l’exploration des solutions et d’orienter notre processus vers les architectures les plus pertinentes, que se soit en terme de qualité ou vis-à-vis des attentes des utilisateurs.
Ces guides influencent le processus d’exploration de différentes manières. Certains permettent d’iden- tifier l’objectif de l’exploration en déterminant la qualité des solutions. Ils définissent la fonction objectif de notre processus d’exploration. Les autres guides permettent de faire une première sélection des solu- tions, en rejetant celles qui sont clairement mauvaises et en orientant l’exploration vers celles qui sont probablement bonnes. Ils définissent l’espace de recherche à partir de l’espace des solutions. Nous pré- sentons donc les guides de notre processus selon deux types : les guides pour l’identification de l’objectif et les guides pour la réduction de l’espace de recherche.
Figure 3.16 – Guides de l’extraction d’architectures
3.4.1 Guides pour l’identification de l’objectif
Déterminer la qualité d’une solution constitue la principale activité d’un processus d’exploration. En effet, celui-ci parcourt l’espace des solutions et doit déterminer à chaque étape la qualité de la solution explorée et ainsi décider s’il s’agit de la meilleure solution rencontrée. La définition d’une mesure de la qualité des solutions est donc requise pour utiliser une approche par exploration. Pour définir cette mesure, appelée fonction objectif, nous utilisons deux guides qui sont la sémantique et la qualité archi- tecturale.
3.4.1.1 Sémantique architecturale
La qualité d’une solution du problème d’extraction tient d’abord au respect de la définition du concept d’architecture. En effet, une partition des classes en contours constitue une bonne architecture si elle correspond à la définition couramment admise du concept architecture, c’est-à-dire si elle correspond à une architecture sémantiquement valide. Nous considérons qu’une architecture est sémantiquement valide si ses éléments (composants, connecteurs et configuration) sont sémantiquement valides.
Nous proposons donc de réifier les propriétés sémantiques des éléments architecturaux pour définir notre fonction objectif. Pour cela, nous avons étudié les définitions des concepts composant et connecteur. A partir de leurs définitions les plus répandues et utilisées, nous avons proposé une définition précise et
correspondant à l’idée couramment admise de ces concepts. Ces définitions nous permettent ensuite de proposer un ensemble de propriétés sémantiques pour ces éléments architecturaux. Ces propriétés doivent être vérifiées par les composants ou les connecteurs pour qu’ils soient considérés comme sémantiquement valides.
Nous utilisons ces propriétés pour définir une mesure de la validité sémantique pour chacun des éléments architecturaux. Ces mesures s’appliquent sur les entités de notre modèle de correspondance et permettent de mesurer la validité sémantique des éléments architecturaux qui correspondent à ces entités. Finalement ces mesures de la validité sémantique sont combinées en une fonction de mesure de la validité sémantique d’une architecture qui s’applique aux éléments de notre espace de solution.
Nous utilisons cette fonction pour mesurer la qualité des solutions rencontrées durant l’exploration. Cette mesure est la fonction objectif de base de notre processus. Elle permet une recherche de solutions correspondant à une architecture.
3.4.1.2 Qualité architecturale
La qualité d’une solution dépend également de la qualité de l’architecture qu’elle représente. En effet, la validité sémantique n’est pas la seule qualité d’une architecture et de nombreux travaux [83] ont établi des listes de qualités pour les architectures telles que la maintenabilité ou la fiabilité.
Baser notre fonction objectif sur les qualités de l’architecture, en plus de sa validité sémantique, permet à notre processus d’extraire une meilleure architecture par rapport à certains objectifs de qualité. Pour cela, nous avons étudié la notion de qualité architecturale et ses caractéristiques. Par cette étude, nous avons choisi plusieurs caractéristiques essentielles pour les architectures. Nous avons également procédé à une analyse similaire pour les différents éléments architecturaux et nous avons obtenu d’autres caractéristiques de qualité portant, cette fois, sur ces éléments.
A partir de ces caractéristiques de qualité, nous proposons un ensemble de mesures pour évaluer les qualités des éléments architecturaux et de l’architecture. Ces mesures permettent de définir une fonction d’évaluation de la qualité architecturale. Finalement, cette fonction peut être combinée avec la fonction de mesure de la validité sémantique pour définir une nouvelle fonction objectif pour notre processus permettant de rechercher une solution correspondant à une architecture de qualité.
3.4.2 Guides pour la réduction de l’espace de recherche
La taille de l’espace des solutions rend nécessaire sa réduction à un espace de recherche plus petit. Pour obtenir cette réduction, nous devons fournir un moyen au processus de se diriger préférentiellement vers les solutions potentiellement bonnes en évitant au maximum l’exploration des solutions qui sont, de manière «évidente», mauvaises.
Nous proposons deux guides permettant de réduire l’espace de recherche. Ils fournissent une des- cription des solutions potentiellement bonnes ainsi que des mauvaises solutions. Ils permettent aussi d’identifier des zones de l’espace des solutions qui contiennent chaque type de solutions (bonnes ou mauvaises).
3.4.2.1 Documentation et recommandations
La documentation d’un logiciel contient de nombreuses informations architecturales. Ces informa- tions décrivent plus particulièrement l’architecture intentionnelle du système. Elles permettent donc d’obtenir une vue architecturale de ce que les concepteurs du système ont souhaité obtenir. Nous souhai- tons utiliser cette vue pour réduire l’espace de recherche de notre processus. Cette réduction intervient
en permettant au processus d’ignorer les solutions qui sont impossibles du point de vue de la documen- tation ou rejetées par l’utilisateur. Cette réduction consiste également à permettre au processus de faire une sélection parmi les solutions contenues dans l’espace de recherche, en fonction de leur adéquation avec l’architecture intentionnelle extraite de la documentation.
Parmi les nombreuses documentations disponibles tout au long du cycle de vie du logiciel, nous avons sélectionné quatre types qui semblent les plus pertinents. Le guide documentation peut ainsi être éclaté en un ensemble de quatre guides (cf. Figure 3.17) : les recommandations de l’architecte, les diagrammes UML, la documentation incluse dans le code source et les outils de versionnement. Nous proposons aussi un modèle de documentation qui permet de facilement prendre en compte un nouveau type de documentation.
Figure 3.17 – Les documents et les recommandations disponibles
Recommandations de l’architecte. L’architecte possède des informations sur le système qui peuvent être plus ou moins précises en fonction de son expertise. Ces recommandations peuvent être de différents types.
D’abord, elles peuvent prendre la forme d’une proposition ou d’une validation. Notre processus permet ainsi à l’architecte de fournir, à différents moments, des propositions d’informations telle qu’une partition des classes en composants. Il interroge également régulièrement l’architecte pour obtenir une validation des résultats. L’architecte peut alors accepter le résultat, le rejeter ou ignorer la demande.
Les recommandations fournies par l’architecte peuvent également prendre la forme d’une informa- tion positive ou négative. Dans le premier cas, l’information met en lumière une relation, alors que le second cas précise l’absence de relation entre entités.
Diagrammes UML. Les diagrammes UML sont utilisés dès les premières étapes du cycle de vie pour modéliser les relations entre les classes et les fonctionnalités qui leurs sont associées. Ces relations entre entités objets et entre fonctionnalités sont utilisées pour obtenir une vue de l’architecture intentionnelle
et donc une vue partielle de l’architecture du système. Nous utilisons cette vue partielle pour identifier les éléments probablement bons de l’espace des solutions ainsi que pour éviter les éléments qui sont en totale contradiction avec la vue architecturale fournie par les diagrammes UML.
Documentation interne au code source. Le code source est un autre type de documents écrits. En effet, il contient des commentaires et des noms d’entités qui sont choisis pour donner une indication sur la sémantique des opérations. Ces informations nous permettent de regrouper les classes en fonction de la partie métier qu’elles réalisent, en utilisant par exemple un algorithme telle que LSA «Latent Semantic Analysis» [79]. Nous utilisons ensuite ces regroupements pour orienter notre processus vers les solutions présentant des regroupements similaires et qui correspondent donc à l’architecture intentionnelle reflétée par les éléments de documentation présents dans le code source.
Outils de versionnement. Les phases de maintenance font souvent l’objet d’un suivi précis. En par- ticulier, les outils de versionnement fournissent des informations sur les modifications apportées aux fichiers et sur la simultanéité de ces modifications. Ces informations établissent des liens entre les entités du code source. Ainsi, deux méthodes modifiées simultanément sont probablement liées par une rela- tion dans le code source ou intentionnelle. Nous proposons d’utiliser les relations identifiées en utilisant les données des outils de versionnement pour calculer une nouvelle vue de l’architecture intentionnelle. Cette vue architecturale permet, comme pour les diagrammes UML, d’identifier les éléments probable- ment bons de l’espace de solutions et d’éviter les éléments qui sont en totale contradiction avec elle.
3.4.2.2 Contexte de déploiement
L’architecture matérielle du système sur lequel le logiciel est déployé a une forte influence sur son architecture. Ainsi, un environnement constitué de nombreuse machines distribuées et disposant de res- sources limitées n’impose pas la même architecture qu’un environnement constitué d’un unique serveur de calcul. Ces contraintes sur le contexte de déploiement peuvent avoir subies des modifications pendant l’évolution du système logiciel. Il est donc essentiel de prendre en compte le contexte de déploiement lorsqu’on réalise l’extraction de l’architecture logicielle.
Par conséquent, nous utilisons les propriétés du contexte pour guider notre processus d’extraction afin d’obtenir une meilleure adéquation entre les architectures matérielles et logicielles. Ainsi, nous utilisons le contexte pour éliminer de l’espace de recherche les solutions qui ne peuvent pas être déployées sur cette architecture matérielle. Par exemple, l’adaptation d’une architecture extraite à une utilisation embarquée impose des limitations sur la taille des composants ou le nombre de connecteurs.
3.5
Conclusion
Nous avons présenté, dans ce chapitre, les motivations et les principes de notre approche. Nous sommes revenus sur les travaux présentés dans le chapitre 2. Nous avons souligné les limites auxquelles ils sont confrontés aussi bien au niveau conceptuel que technique ou des informations utilisées.
Pour pallier ces limitations, nous proposons une approche d’extraction d’architectures logicielles itérative, interactive et semi-automatique. Notre approche utilise des méta-heuristiques pour explorer l’espace des solutions défini par notre modèle COA. Ce modèle établit les correspondances entre les entités objet et les éléments architecturaux. Pour cela, il définit un ensemble d’éléments appellés contours qui sont constitués d’entités objet et associés à un élément architectural.
L’exploration de l’espace des solutions est dirigée par une fonction objectif basée sur la qualité architecturale de la solution et son adéquation avec les définitions du concept d’architecture. Elle s’appuie également sur l’architecture intentionnelle et matérielle pour affiner l’exploration en ciblant les solutions compatibles avec ces architectures. Pour cela, nous avons présenté les principes d’une extraction de l’architecture intentionnelle à partir des recommandations de l’architecte et de la documentation, en particulier les diagrammes UML, les informations contenues dans le code source et les archives des outils de versionnement.