Détection par propagation de contraintes

En ne représentant plus le patron de conception à rechercher, mais en métamodélisant le problème qu’il résout, il est possible de détecter, en utilisant un procédé basé sur les CSP (Constraint Satisfaction Problem), des fragments de modèles remplaçables par des patrons de conception *ElBoussaidi08+. Il ne s’agit plus cette fois de redocumentation, mais vraiment d’aide à l’utilisation des patrons de conception. L’idée est de détecter, dans un modèle, un fragment conforme au métamodèle du problème d’un patron, et ainsi, de remplacer ce fragment par la solution proposée par le patron. Cette technique de détection reformule le problème d’homomorphisme de graphes proposé par [Rudolf00].

I.4.1. Homomorphisme de graphes par CSP

Les algorithmes d’homomorphisme de graphes, connus pour être NP-complets, peuvent être reformulés et résolus en utilisant les CSP [ElBoussaidi08]. Un CSP est défini par un ensemble fini de variables sous un domaine de définition connu, et par un ensemble fini de contraintes spécifiant comment des valeurs peuvent être affectées aux variables [Bacchus98]. Les CSP sont utilisés généralement pour résoudre des recherches complètes avec plusieurs niveaux de retour en arrière. Quand une variable est affectée à une valeur, toutes les contraintes de cette variable sont examinées, ce qui peut provoquer une propagation de contraintes vers les autres variables.

Pour construire un CSP, il est nécessaire de travailler avec deux graphes, celui à rechercher (le graphe source) et celui dans lequel s’effectue la recherche (le graphe destination) [Rudolf00]. Chaque sommet et chaque arc du graphe source sont associés à une variable distincte. Le domaine de définition des variables des sommets et des arcs correspond respectivement à l’ensemble des sommets et des arcs du graphe destination. La construction des contraintes s’effectue ensuite sur les paramètres à comparer pour valider la recherche.

I.4.2. Représentation des patrons de conception par triplets

Selon [Mili05], il est possible de définir les patrons de conception comme des triplets (MP, MS, T), où MP représente le problème résolu par le patron, MS est la solution pour résoudre le problème, et T l’opération de transformation qui permet de transformer MP en MS. En procédant ainsi, ce n’est plus vraiment le patron qui est représenté, mais le problème qu’il résout avec l’opération qui permet de le transformer en solution. MP et MS sont respectivement les métamodèles du problème et de la solution. Lorsqu’un 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. La figure 3.7 présente le métamodèle du problème résolu par le patron de conception Visiteur.

Figure 3.7 : Le métamodèle du problème résolu par le patron de conception Visiteur [ElBoussaidi08] Ce métamodèle montre une hiérarchie de classes qui implémente le même comportement. La racine de la hiérarchie est représentée par la métaclasse ClasseAbstraite qui implémente un certain nombre d’opérations abstraites, par le biais du lien message. Elle a également un ensemble de classes concrètes qui implémentent toutes les opérations abstraites, par le lien méthode. Le fait que toutes les classes concrètes aient une opération concrète pour chaque opération abstraite est représenté par le lien homomorphe à [ElBoussaidi08]. ClasseAbstraite OpérationAbstraite ClasseConcrete OpérationConcrete message +définition +message 0..* méthode +implémentation +méthode 0..* hérite_de +classe_fille +super_classe 1..* implémente +implementation +interface 1..* hérite_de +classe_fille +super_classe 0..* surcharge +redéfinition +surcharge 0..* homomorphe à

I.4.3. Recherche de fragments conformes aux métamodèles de problèmes

Pour rechercher les fragments conformes au métamodèle par CSP, il est nécessaire de définir variables, domaines de définition et contraintes d’après la représentation des patrons. Pour un patron donné, les variables sont extraites de toutes les informations issues du métamodèle (Classifier, Association, Attribute…). Dans le cas de l’exemple présenté dans la figure 3.7, les variables sont : var_ClasseAbstraite, var_ClasseConcrete, var_hérite_de,

var_surcharge… Leur domaine de définition est l’élément du métamodèle du modèle à

analyser. Par exemple, pour une variable de type Classifier, comme var_ClasseConcrete, le domaine de définition est l’ensemble des Classifier du modèle à analyser. En procédant ainsi, la couverture du modèle est totale, et tous les cas sont envisagés. Enfin, les contraintes sont définies par les attributs des métaclasses du métamodèle du patron de conception. Ainsi, chaque contrainte définit les particularités de chaque élément, et donc de chaque variable. Lors de la recherche, chaque élément du modèle à analyser est soumis aux contraintes des variables du patron.

I.4.4. Mise en relation avec notre problématique

Deux limites se détachent de cette approche par CSP. Tout d’abord, le fonctionnement de la méthode est fortement lié à la représentation des problèmes solubles par les patrons. Un problème mal métamodélisé provoque la détection de fragments n’ayant aucun lien avec le patron concerné. Cette représentation par métamodèle doit donc être très précise et obligatoirement manuelle. En effet, il n’est pas possible d’automatiser cette représentation puisqu’à l’exception de la structure, aucune information existante n’est disponible dans le GoF pour concevoir un tel métamodèle. De plus, le fait que cette représentation soit manuelle ajoute un côté subjectif au patron, provoquant la perte du consensus communautaire du patron.

La deuxième limite concerne également le métamodèle, mais sur le fait qu’il ne représente qu’une seule manière de concevoir le problème à résoudre. Il est ainsi nécessaire que le fragment implémente le problème conformément au métamodèle sans aucune différence. Par exemple, si un concepteur a implémenté incomplètement un patron, le fragment n’est pas détectable, car non conforme au métamodèle.

Vis-à-vis de notre problématique, cette approche paraît peu compatible, car nous désirons identifier les mauvaises manières de résoudre un problème, en étant capable de s’adapter aux compétences du concepteur. Ainsi, notre méthode doit être capable de détecter si le concepteur n’a pas utilisé le patron, s’il l’a mal utilisé, ou s’il a utilisé une autre manière de faire. Nous ne pouvons donc pas utiliser ce système de représentation et de détection des patrons pour nos patrons abîmés.