Favoriser l’utilisation des patrons de conception

Favoriser l’utilisation des patrons de conception

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.

Améliorer la classification

En partant du constat que chaque type de patron a son formalisme propre, il est possible d’unifier la représentation des patrons afin de faciliter leur sélection et leur utilisation [Conte01]. De plus, en exprimant une sémantique commune aux formalismes des différents types de patron, il devient possible d’expliciter l’interface de sélection des patrons et de proposer des relations interpatrons permettant d’améliorer l’organisation des catalogues. Pour ce faire, le formalisme utilisé est P-Sigma. Il permet de décrire tout type de patron selon trois rubriques supplémentaires aux rubriques du GoF :

● « Interface » permet de décrire le patron de manière textuelle et formelle selon cinq critères (Identifiant, Classification, Contexte, Problème, Force). Cette rubrique offre au concepteur la possibilité de comparer le patron au type de problème qu’il souhaite résoudre. L’identifiant définit le couple problème/solution à partir duquel le patron pourra être référencé. La classification définit la fonction du patron par un ensemble de mots-clés du domaine. Le contexte décrit textuellement ou formellement la précondition pour l’application du patron. Le problème définit ce que résout le patron, et la force définit les bonnes pratiques inhérentes à l’utilisation du patron.
● « Réalisation » formalise la démarche à suivre pour utiliser correctement la solution proposée par le patron. De plus, cette rubrique donne des exemples d’utilisation du patron, ainsi que les conséquences de son application.
● « Relation » regroupe les patrons compatibles avec le patron concerné, ou les patrons pouvant être utilisés pour le même type de problème dans des cas précis.

Un patron exprimé en P-Sigma est donc décrit par des critères de comparaison comme des mots-clefs ou de bonnes pratiques de conception. Il permet également de fournir une solution au problème posé ainsi que la démarche à suivre pour obtenir cette solution sur le contexte du problème du concepteur. Le patron est ainsi doté d’un guide méthodologique assistant le concepteur pour adapter le patron. Ainsi décrit, le concepteur détient des éléments supplémentaires pour l’aider à choisir et à appliquer un patron de conception. Ce formalisme constitue un apport majeur à l’aide au choix du patron de conception adéquat.

Une des caractéristiques essentielles des patrons de conception est également leur intention. Cette intention est la description de ce que le patron cherche à résoudre. Elle peut être assimilée au problème, mais avec un niveau de granularité plus fine. Ainsi, l’intention du patron peut se décomposer en plusieurs éléments [verbe – complément] décrivant les concepts communs concernés par le patron *Kampffmeyer07+. C’est ainsi que les éléments de l’intention du patron Composite sont « composer des objets », « emboîter des objets » et « construire des structures arborescentes ». En liant les patrons aux éléments formels d’intention et en proposant au concepteur de décrire leurs problèmes en fonction de ces éléments, le choix des patrons s’en retrouve facilité.

Augmenter la précision de la description

Par delà la classification, il est possible que les patrons de conception soient peu ou mal utilisés parce que leur description n’est pas suffisamment précise [Mili05]. En effet, pour pouvoir utiliser correctement un patron de conception, il est nécessaire d’être capable de reconnaître quand il faut l’utiliser, de comprendre ses effets sur le modèle et d’adapter le patron à ses propres besoins, sans altérer ses fondements [Mili05]. En caractérisant formellement le problème résolu par le patron, en le représentant par exemple sous forme de métamodèle, le choix du concepteur peut s’en retrouver facilité. En effet, le fait que le problème soit représenté sous forme de métamodèle permet au concepteur de vérifier si le problème qu’il souhaite concevoir est conforme à ce métamodèle. Les métamodèles permettent de définir un patron comme des triplets (MP, MS, T), où MP représente le métamodèle du problème résolu par le patron, MS le métamodèle de la solution pour résoudre le problème, et T l’opération de transformation qui permet de transformer MP en MS. Ainsi, lorsque le concepteur découvre un fragment de son modèle conforme au métamodèle du problème résolu par le patron, il n’a plus qu’à appliquer la règle de transformation pour modifier le fragment afin qu’il corresponde au métamodèle de la solution [ElBoussaidi08].

Valider l’intégration

La principale difficulté, une fois le patron choisi, est de s’assurer que son adaptation et son intégration dans le modèle n’ont pas provoqué l’apparition de défaut de conception. Cependant, en ajoutant à la description des patrons des règles de transformation, il est possible de décrire formellement quelles modifications il est nécessaire d’effectuer, dans le modèle, pour intégrer le patron [Ammour06] [ElBoussaidi08] [France03]. Ces règles métamodélisent le processus d’intégration en permettant ainsi au concepteur de vérifier si les opérations qu’il effectue pour utiliser le patron sont conformes à ce qui a été prévu par le patron. De plus, un métamodèle présentant la solution résolvant le problème du patron permet également de vérifier si le modèle obtenu, après intégration, est conforme au métamodèle de la solution. Finalement, la principale différence avec la description classique des patrons se situe dans la description de ses caractéristiques par des métamodèles. Comme les auteurs pensent qu’il est possible de vérifier si un modèle est conforme à un métamodèle, il est possible de valider que le modèle issu de l’adaptation du patron de conception soit conforme au métamodèle du patron.

De manière générale, il s’avère que de plus en plus de concepteurs sont amenés à travailler sur des modèles existants ou rétroconçus, dans le but de les étendre à de nouvelles fonctionnalités [Sunyé01]. Ce genre d’extension est souvent précédé d’étapes de restructuration dont le but est d’améliorer la qualité des modèles avant d’en modifier le comportement. À ce moment-là, il ne s’agit plus seulement d’adapter et d’intégrer un patron dans un modèle, mais de restructurer un modèle existant pour y adjoindre un patron de conception [Sunyé01]. Or, comme tout processus de restructuration impose que le comportement original du modèle ne soit pas modifié lors de son exécution, l’injection d’un patron de conception est problématique. En effet, bien que certains patrons de conception se concentrent uniquement sur la structure d’un modèle, il en est d’autres qui s’attachent à imposer une cinématique d’échange de messages. Ainsi, l’injection de ces patrons modifie les aspects comportementaux du modèle d’origine et ne peut donc pas être effectuée par restructuration. Cependant, en autorisant la modification de certaines propriétés comportementales prédéfinies explicitement dans la description d’un patron, il est possible de valider qu’un patron de conception ait été correctement intégré, en vérifiant que seules les propriétés prévues aient été modifiées [Sunyé01] [France03].

Table des matières

Introduction générale
Contexte et Problématique
Contribution
Structuration du mémoire
Chapitre 1 : Les patrons abîmés : contexte
I. Les patrons
I.1. Patrons logiciels
I.2. Patrons de conception
II. Favoriser l’utilisation des patrons de conception
II.1. Améliorer la classification
II.2. Augmenter la précision de la description
II.3. Valider l’intégration
II.4. Recherche de défauts de conception dans un modèle
III. Les patrons abîmés
III.1. Hypothèses de travail
III.2. Définitions
III.3. Illustration des concepts
III.4. Patrons abîmés, bad smells et antipatterns
III.4.1. Les bad smells
III.4.2. Les antipatterns
IV. Une activité de revue de conception
IV.1. Présentation
IV.2. Illustration
IV.2.1. Le modèle à analyser
IV.2.2. Revue de conception
IV.2.3. Le modèle amélioré
V. Conclusion
Chapitre 2 : Création d’une base de patrons abîmés
I. Recherche de solutions alternatives
I.1. Élaboration des expérimentations
I.2. Limites de notre approche par expérimentations
II. Analyse des résultats
II.1. Analyse complète des solutions alternatives au Composite
II.2. Autres expérimentations pour les patrons structurels
II.2.1. Une solution alternative non détectable structurellement
II.2.2. Des solutions alternatives déjà présentées dans le GoF
II.2.3. Les patrons Adaptateur, Façade, Poids-mouche et Procuration
II.3. Patrons abîmés déduits
III. Problèmes de décontextualisation
III.1. Les patrons comportementaux
III.2. Les patrons composites
IV. Conclusion
Chapitre 3 : Détection et transformation de fragments alternatifs dans un modèle
I. Techniques de détection de fragments
I.1. Modèle UML et graphes
I.1.1. Pattern matching exact
I.1.2. Pattern matching approché
I.2. Identification par comparaison de similarités
I.2.1. Modèle UML et représentation matricielle
I.2.2. Comparaison des similarités de graphes
I.2.3. Mise en relation avec notre problématique
I.3. Détection par évaluation floue de modèles UML
I.3.1. Définition structurelle des patrons
I.3.2. Détection semi-automatique
I.3.3. Mise en relation avec notre problématique
I.4. Détection par propagation de contraintes
I.4.1. Homomorphisme de graphes par CSP
I.4.2. Représentation des patrons de conception par triplets
I.4.3. Recherche de fragments conformes aux métamodèles de problèmes
I.4.4. Mise en relation avec notre problématique
I.5. Synthèse vis-à-vis de notre problématique
II. Concordances structurelles
II.1. Concordance des particularités structurelles
II.2. Participant de référence
II.3. Relations autorisées, interdites ou facultatives
II.4. Algorithme de détection
II.5. Conséquences de la détection sur la transformation
II.6. Mise en œuvre
III. Validation
III.1. Tests unitaires
III.1.1. Mode opératoire
III.1.2. Résultats globaux
III.1.3. Analyse des résultats
III.2. Tests aux limites
III.2.1. Mode opératoire
III.2.2. Analyse de modèles sélectionnés
III.2.2.1. Relations entre deux participants multipliés
III.2.2.2. Ordre d’exécution des transformations
III.2.2.3. Gestion ensembliste des liens interdits
IV. Conclusion
Chapitre 4 : Concrétisation de l’approche
I. Génération des requêtes
I.1. Description des liens autorisés, interdits et facultatifs
I.2. Génération automatique de requêtes
I.2.1. Construction d’une requête de détection
I.2.1.1. Recherche du participant de référence
I.2.1.2. Recherche des particularités locales
I.2.1.3. Le cas particulier des relations réflexives
I.2.1.4. Construction d’une opération de démêlage
I.2.1.5. Recherche des particularités globales
I.2.1.6. Assemblage de la requête de détection
I.3. Génération et exécution des opérations de transformation
I.3.1. Différenciation du patron abîmé par rapport au patron de conception
I.3.2. Construction des opérations de transformation
I.3.3. Exécution des opérations de transformation
I.4. Limite de l’utilisation d’OCL
II. Explications au concepteur
II.1. Design Pattern Intent Ontology (DPIO)
II.1.1. Ontology Web Language (OWL)
II.1.2. Description de l’ontologie DPIO
II.1.3. Utilisation de l’ontologie DPIO
II.2. Extension de l’ontologie DPIO
II.2.1. Conception
II.2.2. Utilisation
III. Validation sur des cas concrets
III.1. Mode opératoire
III.2. Analyse et résultats globaux
IV. Conclusion
Conclusion

Lire le rapport complet