Mise en œuvre

Nous avons choisi d’utiliser OCL pour encoder nos requêtes de détection. OCL est un langage de contraintes utilisé pour ajouter de la sémantique aux modèles UML [OMG06]. Il permet de définir des invariants sur des éléments du modèle que le système devra respecter. Ces contraintes n’ont aucun effet de bord sur le modèle et peuvent être utilisées

Composant Feuille Composite * * Composant Composite Feuille *

sur des métamodèles pour définir, en autres, des règles de bonne formation des modèles. Il est ainsi possible d’interdire, par exemple, des cycles dans les liens d’héritage. Les contraintes OCL sont donc des expressions booléennes caractérisant l’ensemble des instances valides exprimées dans un modèle ou un métamodèle.

La plate-forme Neptune a été développée par notre équipe dans le cadre d’un projet européen de même nom [Millan08]. L’interprète OCL qu’elle propose, conforme à la norme OCL 2.0 [OMG06], met en œuvre deux extensions d’OCL *Millan09+. La première permet l’écriture de contraintes ayant un effet de bord sur les modèles afin de pouvoir les transformer, la deuxième concerne les requêtes qui peuvent retourner un résultat de n’importe quel type du métamodèle, ce qui introduit la notion de vue d’un modèle.

Afin de pouvoir profiter des capacités de Neptune, nous avons décidé de détecter les fragments alternatifs en utilisant OCL. Nous souhaitions ainsi décrire des requêtes sous une forme compréhensible par un concepteur, lui permettant éventuellement de les adapter à ses besoins. La deuxième extension de l’interprète de Neptune nous est très utile dans le contexte de notre activité. Nous utilisons la capacité des requêtes à retourner un résultat de n’importe quel type du métamodèle, pour effectuer notre recherche de fragment alternatif dans un modèle. Nous avons associé à chaque patron abîmé une requête OCL retournant un ensemble d’ensembles de classes, chaque ensemble représentant un fragment alternatif composé d’un ensemble de participants. En utilisant ce type de requête sur la plate-forme, nous profitons d’un outil efficace capable de parcourir un modèle en fonction de son métamodèle.

En ce qui concerne l’injection du patron, nous n’avons pas utilisé directement l’extension d’OCL liée aux transformations. Nous avons préféré transformer le modèle directement en mémoire, nous distinguant ainsi de la détection. Ce choix est motivé par le fait que Neptune n’effectue pas de transformation sur place. Sur un gros modèle, ce mode de transformation provoque donc la recopie de toutes les métaclasses. Cette contrainte ne pose pas de problème pour une transformation occasionnelle, mais notre activité pouvant être amenée à transformer plusieurs fois le modèle, le temps d’exécution et la consommation mémoire sont bien trop importants sur des modèles industriels. En transformant en mémoire comme nous le faisons actuellement, nous évitons un grand nombre de recopies.

III. Validation

Pour valider notre algorithme de détection et de substitution de patrons abîmés, nous avons réalisé un jeu de tests, décomposé en deux parties. Notre objectif était de valider notre approche de détection et de transformation des fragments sous la forme la plus simple possible, puis sous une forme prédéfinie. Un fragment avec une forme la plus simple possible est strictement identique aux patrons abîmés sans contextualisation. En ce qui concerne les formes prédéfinies, les fragments contenaient des multiplications, des liens interdits et des attributs facultatifs, afin de constituer des cas de tests aux limites de notre approche. Pour réaliser ces tests, nous avons utilisé notre outil permettant l’exécution de l’activité, ainsi que les requêtes OCL de détection. Cet outil, que nous avons nommé Triton, et les requêtes OCL utilisées sont détaillés dans le chapitre 4 de cette thèse.

Nous avons découpé cette section en deux parties, correspondant chacune à deux types de tests que nous avons effectués : les tests unitaires et les tests aux limites. Dans chacune des parties, nous présentons le mode opératoire suivi pour réaliser les tests, et les résultats obtenus. Durant toute cette section, afin d’améliorer la lisibilité des statistiques, nous avons associé un identifiant à chaque patron abîmé. Le tableau 3.5 présente la relation entre ces identifiants et les patrons abîmés.

Identifiant Patron de

conception Patron abîmé

C_SP1 Composite Développement de la composition sur <<Composant>> C_SP2 Composite Développement de la composition sur <<Composant>> et sur

<<Composite>> C_SP3 Composite Composition récursive

C_SP4 Composite Développement de la composition sur <<Composite>> sans conformité de protocole

C_SP5 Composite Développement de la composition sur <<Composite>> C_SP6 Composite Composition indirecte de la composition sur <<Composite>> D_SP1 Décorateur Développement sur <<Décorateur>>

D_SP2 Décorateur Développement sur <<Décorateur>> sans conformité de protocole D_SP3 Décorateur Développement sur <<Composant>>

D_SP5 Décorateur Mauvais découplage

D_SP6 Décorateur Mauvais découplage sans possibilité d’extension sur <<Composant>> D_SP7 Décorateur Non conformité entre décorateurs et objets à décorer

P_SP1 Pont Développement du pont

Tableau 3.5 : Table de correspondance des symboles des patrons abîmés

Les patrons abîmés D_SP4, P_SP2 et P_SP3 n’ont pas été intégrés à ce tableau car ils ne sont pas détectables en l’état actuel de notre approche, comme indiqué au chapitre 2.