Détection, Explications et Restructuration de défauts de conception : les patrons abîmés

Les patrons

 C’est un architecte du nom de Christopher Alexander qui a, le premier, étudié les patrons dans le bâtiment et les collectivités. Il a constaté qu’au fil des siècles, les grands bâtisseurs n’ont pas suivi de modèles préétablis avec des règles rigoureuses pour ériger leurs édifices, mais que les architectures avaient été adaptées les unes après les autres à leur environnement. Il a également remarqué, malgré leurs adaptations aux différentes situations, une certaine récurrence dans les solutions de conception considérées comme efficaces. Il a alors mis au point un langage de patrons permettant à des non-architectes de construire eux-mêmes leur propre édifice. Ce langage est structuré en un ensemble de patrons dont chacun permet de résoudre un problème. Selon lui, chaque patron concerne un problème qui se manifeste constamment dans notre environnement et décrit le cœur de la solution de ce problème, d’une façon telle qu’il est possible de réutiliser plusieurs fois cette solution sans jamais le faire deux fois de la même manière [Alexander77]. Le tableau 1.1 présente un des patrons d’Alexander. Patron Domaine du couple Problème Comment éviter que la présence d’enfants dans une famille ne détruise la proximité et l’intimité nécessaire à un homme et une femme ? Solution Construire une zone spéciale dans la maison distincte des zones communes et des chambres des enfants, où l’homme et la femme peuvent se retrouver en privé. Donner à cette zone un accès rapide à la chambre des enfants, mais, en conservant à tout prix, une séparation distincte. Tableau 1.1 : Le patron Domaine du couple d’Alexander Ce patron est intéressant de par la relative simplicité du problème qu’il résout. La première partie de la solution semble particulièrement évidente, puisqu’il suffit de créer une zone d’intimité séparée de la zone d’évolution des enfants pour résoudre le problème. Cependant, c’est la deuxième partie qui apporte toute la force à ce patron. Pour conserver une « contrainte » de surveillance permanente des enfants, le patron suggère de placer la zone d’intimité à proximité de la zone des enfants. Ainsi, la surveillance peut être maintenue tout en conservant un minimum d’intimité. Dans cette section, nous présentons dans une première partie les patrons tels que le génie logiciel les utilise. Nous montrons que les patrons d’Alexander ont été déclinés suivant les différentes étapes du cycle de vie d’un logiciel, chaque type de patron étant décrit avec une base commune. Cette base permet de définir le contexte et la manière d’utiliser un patron. Nous nous intéressons dans une deuxième partie à une catégorie particulière de Chapitre 1 : Les patrons abîmés : contexte 11 patrons : les patrons de conception. Ils ciblent essentiellement des problèmes pouvant apparaître lors de la phase de conception des logiciels. En utilisant le catalogue du « Gang of Four » (GoF) comme référence, nous décrivons les trois types de patrons de conception existants, en montrant le type de problème qu’ils sont le plus à même de résoudre. 

Patrons logiciels

 La première adaptation à la conception et à la programmation par objets, du langage de patrons d’Alexander, a été présentée à la conférence OOPSLA de 1987 par Kent Beck et Ward Cunningham [Beck87]. Depuis, de nombreuses classifications de patrons ont été déclinées : c’est ainsi que l’on parle aujourd’hui de « patrons architecturaux » [Buschmann96], de « patrons d’analyse » [Fowler97] et de « patrons de conception » [Gamma95], ciblant une ou plusieurs étapes du cycle de vie d’un logiciel. Il existe également des « patrons de patrons » [Larman00], des « patrons composites » [Riehle97_b] et bien d’autres *Ambler98+, *Booch97+, *Coad95+, *Coplien96+, dont les spécificités concernent d’autres aspects de la construction d’un logiciel. Quel que soit son domaine d’application, un patron est au minimum décrit grâce à trois éléments essentiels, un nom, une intention et une solution. Tout d’abord, le nom est choisi de manière à décrire en un ou deux mots un type de problème ou une solution. Le nom est souvent utilisé pour identifier le patron parmi d’autres. Son choix est donc très important et nécessite une précision suffisante pour pouvoir le discerner et le reconnaître. L’intention est présentée de manière à décrire un problème récurrent que le patron de conception est à même de résoudre. Enfin, la solution met en avant la manière de résoudre le problème en donnant les procédures à suivre ou les éléments à utiliser. Les patrons architecturaux [Buschmann96] représentent des organisations structurelles fondamentales de systèmes informatiques complets. Ils fournissent un ensemble de sous-systèmes prédéfinis, spécifient leurs responsabilités et organisent les relations entre eux. L’exemple le plus connu est le patron Modèle-Vue-Contrôleur (MVC), introduit par les concepteurs de SmallTalk [Krasner88] et décrit dans le tableau 1.2.

Favoriser l’utilisation des patrons de conception

a Un concepteur désireux d’utiliser un patron de conception doit identifier quel type de problème il souhaite résoudre, et reconnaître ce type de problème dans le GoF. Or, les problèmes du GoF sont génériques de manière à pouvoir s’adapter à n’importe quel contexte de problème. Ainsi, la principale difficulté consiste à s’abstraire du contexte du problème en cours de résolution, pour pouvoir le comparer aux problèmes présentés dans le GoF. Après avoir identifié le patron adéquat, le concepteur doit s’assurer qu’il a intégré correctement le patron dans son modèle, afin que cette intégration n’ait pas de conséquences négatives. En effet, si l’adaptation du patron au contexte du problème est mal effectuée, le modèle peut s’en trouver dégradé *Huston01]. Il est donc très important pour un concepteur de s’assurer qu’il a utilisé le patron comme il a été prévu. Ceci n’est pas une chose simple, surtout pour un concepteur utilisant pour la première fois un patron. Malgré les détails d’utilisation, la structure et les conseils inscrits avec chaque patron dans le GoF, leur utilisation est toujours sujette au contexte du problème et à l’expérience propre du concepteur. Pour illustrer cette problématique, imaginons qu’un concepteur cherche à résoudre le problème « permettre à l’utilisateur d’effectuer un undo/redo ». Lors de sa recherche dans le GoF, il identifie deux patrons de conception dont l’intention semble correspondre. Ces deux patrons sont le Mémento et la Commande, dont leur intention respective est « saisir et transmettre à l’extérieur d’un objet son état interne dans le but de pouvoir le restaurer ultérieurement dans cet état » et « encapsuler une requête comme un objet, autorisant ainsi leur exécution sur des clients, ainsi que leur réversion ». Si le concepteur ne maîtrise pas suffisamment les patrons de conception, il ne saura pas lequel choisir. Le Mémento est capable de restaurer l’état d’un objet et la Commande permet de mémoriser des opérations pour éventuellement les annuler. La nuance entre les deux est donc subtile. De plus, pour doter une application d’un système de « undo/redo », il est souvent nécessaire de mémoriser l’état d’un objet ainsi que les commandes exécutées. Dans ce cas, l’utilisation combinée des deux patrons s’avère nécessaire : l’un pour profiter de sa capacité à sauvegarder des états et l’autre pour sauvegarder des actions. Il est donc nécessaire d’aider les concepteurs à utiliser les patrons de conception, de manière à ce qu’ils puissent choisir facilement quel patron utiliser et comprendre comment ils doivent l’adapter au contexte de leur problème. Pour ce faire, des travaux améliorant la classification et la description des patrons existent, ainsi que des méthodes pour vérifier la bonne intégration d’un patron. Cependant, ces travaux ne permettent pas de suggérer, a posteriori, l’intégration de patrons de conception dans un modèle.