C HAPITRE 5 Guider le processus
5.3 Création d’un réseau de contrainte hiérarchique
Nous avons montré comment utiliser la documentation et les recommandations de l’architecte pour ob- tenir une vue de l’architecture intentionnelle. Cette architecture intentionnelle permet de réduire l’espace de recherche en ciblant un sous-ensemble de l’espace des solutions.
Ce ciblage n’est pas, comme on l’a vu, le seul moyen de réduire l’espace de recherche de notre processus. Afin de pouvoir supprimer des éléments de l’espace de recherche, nous devons proposer un processus de génération d’un réseau de contraintes hiérarchiques conformément à notre modèle d’in- formations pour la suppression. Pour cela, il nous faut déterminer les sources d’informations qui nous permettent de définir les contraintes, mais aussi celles qui nous permettent d’établir le niveau de la contrainte dans la hiérarchie du réseau.
Nous présentons, dans la suite, comment nous utilisons les recommandations de l’architecte pour définir une partie des contraintes de notre réseau. Ensuite, nous étudions les mécanismes qui nous per- mettent de définir des contraintes à partir des architectures intentionnelles extraites de la documentation. Enfin, nous exposons le processus de génération du réseau de contraintes proprement dit à partir des contraintes établies.
5.3.1 Les recommandations de l’architecte
La première source d’information lors de l’extraction est l’architecte. Il connait l’environnement de déploiement du système, les raisons de l’extraction d’architectures ainsi que les objectifs des prochaines phases de maintenance. De plus, selon son expertise, il possède des connaissances plus ou moins pro- fondes sur le système qui peuvent lui permettre d’avoir une vue partielle de l’architecture.
Nous souhaitons utiliser ces informations pour définir un ensemble de contraintes permettant de réduire l’espace de recherche en supprimant les solutions qui ne les respectent pas. L’objectif est d’utiliser les connaissances de l’architecte pour éliminer les solutions qui sont, de manière évidente pour lui, incorrectes et en favorisant les solutions qui lui semblent correctes.
Pour cela, nous étudions les informations qu’il peut nous offrir du point de vue des intentions des concepteurs et du contexte de déploiement. Nous présentons ensuite la méthode de collecte que nous utilisons pour récupérer les recommandations de l’architecte.
5.3.1.1 Informations contextuelles
Nous avons vu les atouts que représentent les informations contextuelles dans le cadre de l’extraction d’architectures. Cependant, l’obtention de ces informations n’est pas facile. Il existe des outils qui per- mettent d’obtenir les éléments du contexte sous différentes formes manipulables par ordinateur, mais ces informations ne peuvent pas être utilisées dans notre approche. En effet, comme l’extraction porte sur un système existant, nous ne pouvons pas le modifier totalement pour obtenir une architecture respectant des limitations liées au contexte trop précises. Ainsi, nous ne pouvons pas garantir la taille mémoire représentée par un composant extrait puisque cette taille dépend directement de la taille des classes du contour de composants.
Afin d’utiliser les informations contextuelles, nous utilisons l’architecte pour fournir des informa- tions portant sur le contexte et utilisables dans notre approche. Pour cela, nous demandons à l’architecte de spécifier un ensemble d’informations portant sur les entités COA et objets et représentant les limites liées au contexte auxquelles le système sera confronté. Il doit donc traduire les limites du contexte en li- mites sur les entités COA et objets. Par exemple, les limitations de mémoire seront traduites en limitation
sur le nombre de classes ou méthodes par contour. Les limitations en termes de communications peuvent être traduites en un nombre maximum de contours de connecteurs ou en une contrainte sur le diamètre des appels de méthodes dans les contours de connecteurs.
5.3.1.2 Informations intentionnelles
Pour permettre à l’architecte de fournir toutes les informations dont il dispose, notre approche doit prendre en compte toutes informations partielles qu’il possède. Pour cela, notre processus doit accepter les propriétés positives et négatives, c’est-à-dire les propriétés qui décrivent respectivement une relation entre deux entités ou l’absence d’une telle relation. Par exemple, l’architecte peut nous indiquer que deux classes doivent appartenir au même contour de composant (information positive) ou qu’elles ne doivent pas appartenir au même contour (information négative).
Cependant, en fonction de l’expertise de l’architecte, nous pouvons aussi obtenir des informations plus complètes. Ainsi, l’architecte peut connaitre les classes du système qui constituent un composant ou les méthodes qui constituent un connecteur. Il peut même indiquer une architecture du système qui lui semble correcte. Dans ce cas, l’objectif de notre processus est d’affiner sa proposition.
5.3.1.3 Collecte des recommandations
Les recommandations de l’architecte peuvent concerner différents types d’informations. De la même manière, elles peuvent prendre plusieurs formes selon le type d’informations qu’elles portent : infor- mations contextuelles, informations intentionnelles partielles, informations intentionnelles complètes. Cependant, toutes ces formes sont des contraintes selon notre modèle d’information pour la suppression. De plus, le niveau de confiance de chacune de ces contraintes est par défaut de 2, c’est-à-dire le niveau maximum de confiance, puisque l’architecte les impose. Cependant, nous permettons à l’architecte de modifier le niveau de confiance pour souligner une hésitation.
Informations contextuelles. Les limites que l’architecte définit sur les entités COA et objets per- mettent de détecter les solutions qui ne sont pas correctes du point de vue du contexte. Pour permettre cette détection et faciliter la collecte de ces informations, nous proposons de définir ces limites à travers des contraintes portant sur les entités COA et objets.
Les limites de chaque entité COA s’expriment, en effet, facilement en termes de contraintes portant à la fois sur les entités COA et les éléments objets. Par exemple, les limites en nombres de classes par contour de composants sont collectés sous la forme d’une contrainte impliquant les contours de composants et les classes objets et limitant le nombre de classes par contour de composants.
Les informations contextuelles sont fournies par l’architecte en définissant des contraintes mixtes de notre modèle d’informations pour la suppression.
Informations intentionnelles complètes. Nous utilisons d’abord les informations complètes propo- sées par l’architecte pour orienter notre processus vers une solution correspondant à ces attentes et cor- recte selon nos autres guides. Si ces informations sont suffisamment conséquentes (proposition d’archi- tecture), nous utilisons notre processus uniquement pour améliorer la solution proposée.
Ces informations intentionnelles complètes définissent des entités COA que l’architecte attend dans l’architecture résultant de l’extraction. Notre processus d’exploration doit donc veiller au respect des recommandations de l’architecte en favorisant les solutions comportant ses entités. Pour cela, nous pro- posons de définir ces informations à travers des contraintes portant sur les entités objets. En effet, chaque entité COA peut être définie comme une contrainte sur les entités objets. Ainsi, on crée une contrainte
imposant aux éléments objets de l’entité COA d’appartenir à la même entité COA. Par exemple, si l’ar- chitecte souhaite un contour de composants, qui contient les classes a et b, on crée une contrainte sur a et b qui impose aux deux classes d’appartenir au même contour de composants.
Les informations intentionnelles complètes sont fournies par l’architecte en définissant des con- traintes objets de notre modèle d’informations pour la suppression.
Informations intentionnelles partielles. Nous utilisons les informations partielles que l’architecte fournit pour détecter les solutions qui ne sont pas correctes de son point de vue. Pour permettre cette détection et faciliter la collecte de ces informations, nous proposons de définir ces informations au tra- vers de contraintes portant sur les entités COA ou sur les entités objets.
L’architecte peut en effet proposer des informations nécessitant la définition de contraintes portant sur les entités objets ou les entités COA. Par exemple, si deux méthodes doivent appartenir à un connecteur, nous définissons une contrainte portant sur les deux méthodes et imposant qu’elles appartiennent à un seul contour de connecteur. Par contre, si l’architecte veut signaler un nombre maximum de composants dans l’architecture, il doit définir une contrainte portant sur le nombre de contours de composants dans la solution.
De plus, les propriétés affirmatives ou négatives s’expriment facilement en termes de contraintes portant sur les entités objets ou COA. Par exemple, si deux classes a et b doivent appartenir au même contour de composant, l’architecte soumet une contrainte sur l’ensemble de classes {a, b} imposant l’égalité entre les contours de chaque élément de l’ensemble. Inversement, si deux classes a et b doivent appartenir à des contours différents, l’architecte soumet une contrainte sur l’ensemble de classes{a, b} imposant une inégalité entre les contours de chaque élément de l’ensemble.
5.3.2 Les contraintes issues des architectures intentionnelles
Les informations issues de la documentation donnent une vue partielle de l’architecture du système. A ce titre, nous avons montré comment elles permettent directement de définir des solutions au problème d’extraction et de les utiliser comme point de départ pour l’exploration. Cependant, les informations issues de la documentation ne sont pas des contraintes.
Pour pouvoir utiliser l’architecture intentionnelle extraite de la documentation, nous devons transfor- mer les entités du modèle d’information pour le ciblage en entités du modèle de transformation pour la suppression.
L’architecture intentionnelle est un ensemble de contours de composants. C’est donc avant tout une partition des classes objets. De manière similaire à la méthode utilisée pour les informations inten- tionnelles complètes de l’architecte, nous transformons d’abord chaque contour de composant en une contrainte. Cette contrainte porte sur l’ensemble des classes du contour et impose que les classes appar- tiennent au même contour de composant.
Cette contrainte est cependant insuffisante pour représenter parfaitement la partition. En effet, une architecture intentionnelle de deux contours de deux classes chacun donne deux contraintes de ce type. Mais, la reconstruction de l’architecture intentionnelle, à partir des contraintes, n’est pas unique puisque ces deux contraintes sont vérifiées à la fois par l’architecture intentionnelles initiale et par une architec- ture composée d’un seul contour de composant réunissant toutes les classes.
Pour éviter cela, nous définissons une autre contrainte à partir de l’ensemble des contours de com- posants. Nous devons ajouter une contrainte qui interdit à deux classes issues de contours différents d’appartenir au même contour. Pour cela, nous créons une contrainte de ce type entre chaque paire de classes appartenant à des contours différents.
Pour compléter la transformation entre les deux modèles nous devons définir le niveau de confiance de chaque contrainte. Pour cela, nous utilisons les interventions de l’architecte pour juger de la confiance qu’il porte à l’architecture intentionnelle (cf. Figure 5.9).
Si l’architecte rejette les informations à n’importe quelle étape le document n’est pas utilisé et pos- sède un niveau de confiance nul. Les autres interventions permettent d’obtenir une architecture intention- nelle et donc un ensemble de contraintes. La première validation donne le niveau de confiance initiale pour le document et donc l’architecture. Si l’architecte ignore les informations, le niveau de confiance est nul, c’est-à-dire non vérifié. Par contre s’il valide les informations, le niveau de confiance est de 1, c’est-à-dire que les informations sont validées par l’architecte. Enfin, s’il modifie les informations, le niveau de confiance est de 2, c’est-à-dire que les informations sont proposées par l’architecte et que le niveau de confiance est maximum.
Les étapes suivantes de validation modifie le niveau de confiance initiale. Si l’architecte ignore une étape de validation le niveau de confiance diminue de 1. S’il valide une étape de validation, le niveau de confiance reste identique. Enfin, si l’architecte modifie les informations le niveau de confiance augmente au niveau 2.
5.3.3 Combinaison des contraintes
Les contraintes que nous avons extraites des recommandations de l’architecte, du contexte et de la documentation doivent être assemblées pour former le réseau de contraintes hiérarchiques, instance du modèle d’information de suppression (cf. Figure 5.10).
L’assemblage de l’ensemble des contraintes nous donne un réseau hiérarchique, où la hiérarchie est déterminée par le niveau de confiance de chaque contrainte dans le réseau. Cependant, étant donné la diversité des sources des contraintes il est possible qu’il existe des conflits entre les contraintes rendant le réseau inconsistant. Il nous faut donc assurer la consistance de ce réseau.
Pour assurer cette consistance, nous procédons par niveau. Ainsi, nous vérifions d’abord la consistance de chaque niveau. Si deux contraintes sont en conflit, l’architecte peut, s’il est disponible, choisir celle à conserver. Si l’architecte n’est pas disponible, nous supprimons l’une des deux au hasard.
Nous vérifions ensuite la consistance entre les niveaux. Si deux contraintes, de niveaux différents, sont en conflits, nous supprimons la contrainte du plus bas niveau puisque c’est la contrainte qui a le moins de confiance.
5.4
Conclusion
Dans ce chapitre, nous avons étudié les guides auxiliaires de l’extraction. Ces guides permettent d’étendre les sources d’informations utilisées par le processus d’extraction au-delà du code source. L’ar- chitecture reflète ainsi le système dans son ensemble et non plus simplement son implémentation.
Nous avons d’abord proposé deux modèles d’informations permettant d’utiliser les informations intentionnelles et contextuelles pour guider l’exploration. Ainsi, les instances de ces modèles permettent de diriger l’extraction en réduisant l’espace de recherche. Cette réduction repose à la fois sur une sup- pression des solutions évidement incorrectes et sur le ciblage des solutions probablement bonnes.
Nous avons ensuite proposé un processus d’extraction des informations intentionnelles et contex- tuelles. Cette extraction est faite depuis trois types de documents que sont les diagrammes UML, les fichiers sources et les archives des outils de versionnement.
Figure 5.10 – Utilisation de la documentation et des recommandations
L’ensemble du processus d’extraction de l’architecture intentionnelle et des contraintes contextuelles est conçu pour être « à la disposition » des experts. En effet, si un architecte est disponible, il peut grandement influencer les éléments extraits de la documentation et donc agir sur le processus d’extraction d’architectures utilisant ces guides. Dans le cas ou l’architecte est peu ou pas disponible, il peut se reposer sur des mécanismes automatiques qui, s’ils sont moins efficaces, permettent d’utiliser les informations intentionnelles malgré le manque de disponibilité des experts.