Analyse et résultats globau

Les résultats de nos analyses sont présentés dans le tableau 4.6.

Modèle ArgoUML JHotDraw JRefactory Neptune X1 X2

Nombre d’instances de

métaclasses 79808 316977 672662 28011 230999 798539

Nombre de classes 2476 1749 1843 904 201 202

Nombre d’associations 1971 388 1498 433 6 6

Nombre de généralisations 1459 330 993 334 193 193

Temps d’analyse en minutes 28 7 4 14 0,01 0,01

Nombre de fragments identifiés 41 10 28 5 0 0 Nombre de fragments incomplets 2431 72 220 168 0 0 Nombre de fragments alternatifs 0 0 0 1 P_SP1 0 0 Nombre de mauvaises intentions 41 10 28 7 0 0

Tableau 4.6 : Résultat des analyses des modèles industriels

Il est important de préciser que la ligne indiquant les temps d’exécution n’est qu’indicative puisque Neptune intègre un système de cache qui accélère la détection au fur et à mesure de l’exécution des requêtes. Cependant, l’effet filtrant des requêtes se retrouve dans ces temps d’exécution, puisque des modèles avec très peu d’Association, et donc très peu de fragments candidats, ont été analysés en des temps inférieurs à la minute.

Nous n’avons pas pu identifier de manière significative des fragments alternatifs, signes de mauvaises pratiques de conception. Cependant, le fait que ces modèles aient été rétroconçus a altéré leur pertinence. Le nombre de fragments incomplets pour chacun de ces modèles met en évidence leur faiblesse structurelle. En ce qui concerne les modèles X1 et X2, il est possible de remarquer le nombre d’associations est beaucoup trop faible pour être significatif. Il est particulièrement surprenant que des entreprises élaborent un modèle de conception avec seulement six associations pour deux cents classes. Ces deux modèles n’ont donc présenté aucun intérêt en l’état. Après avoir analysé les fragments complets, nous n’avons trouvé qu’un seul fragment que nous considérons comme réellement alternatif. Tous les autres avaient une intention différente de celle du patron.

À l’issue de nos tests sur des modèles industriels, nous pouvons conclure que Triton est capable d’analyser en détail et de présenter des résultats cohérents dans des délais plus que raisonnables, qu’il s’agisse de petits modèles ou de plus gros dépassant les sept cent mille métaclasses. En effet, grâce à notre approche par filtrages successifs, le temps de détection n’est pas directement lié au nombre d’instances de métaclasses, mais au nombre de fragments potentiellement identifiables. Ainsi, nous pouvons dire que nous proposons une activité de revue de conception efficace, visant à corriger, par l’utilisation de patrons, des mauvaises pratiques de conception.

IV. Conclusion

En réunissant sur un même modèle l’intégralité des informations nécessaires à la détection d’un patron abîmé, nous avons pu développer un générateur de requêtes OCL. En considérant le patron abîmé comme un graphe, le générateur analyse tous les chemins possibles entre chaque sommet et les convertit en représentation arborescente dont chaque nœud représente une métaclasse du patron abîmé. Ainsi, chaque arbre décrit les métaclasses à traverser pour se déplacer d’un participant à un autre. Le patron abîmé étant décrit avec le profil UML précisant les liens interdits, le générateur mémorise au travers des arbres, les chemins autorisés et interdits. Cette transformation du modèle en arbre nous permet de générer des sous-requêtes permettant, lors de l’exécution de l’activité, d’identifier, dans le modèle à analyser, si des arbres similaires sont présents. Grâce à un algorithme de couplage de ces sous-requêtes, le résultat de chacune d’entre elles provoque l’identification d’un fragment.

Ce générateur nous permet ainsi de construire des requêtes de détection particulièrement complexes, intégrant la totalité de nos concepts de particularités structurelles locales et globales, ainsi que de liens autorisés, facultatifs et interdits. En complément, le générateur est également capable de construire les opérations d’injection de patron de conception. En comparant structurellement un patron abîmé à son patron de conception, le générateur met en évidence leurs différences structurelles, qu’il intègre dans les opérations de transformation. Ainsi, la transformation d’un fragment alternatif en contextualisation d’un patron de conception se résume à la correction des différences structurelles.

Intégrées dans Triton, notre outil permettant l’exécution de la revue de conception, ces requêtes concrétisent la première et la dernière étape de l’activité. En ce qui concerne la deuxième étape, consistant à communiquer avec le concepteur, nous avons utilisé une ontologie existante orientée sur l’intention des patrons de conception. Nous l’avons utilisée et étendue pour qu’elle nous permette de construire des questions à poser au concepteur. Ces questions vérifient que l’intention des fragments identifiés est conforme à celle du patron abîmé et présente au concepteur les avantages d’un remplacement de ces fragments par les patrons de conception adéquats. Nous avons ainsi étendu l’ontologie existante en y ajoutant le concept de points forts perturbés par le patron abîmé. Nous pouvons donc montrer au concepteur quels sont les points forts dont il peut bénéficier dans son modèle.

Synthèse

Identifier dans un modèle, a posteriori, des défauts de conception issus d’un manque d’utilisation de patrons de conception constitue le principal intérêt de notre approche. Nous avons alors développé une technique qui permet d’assister le concepteur dans l’utilisation des patrons et ce même s’il n’a pas eu le réflexe de les exploiter pendant sa conception. Pour ce faire, nous recherchons des défauts de conception, par le biais de patrons abîmés. Grâce à des requêtes de détection générées automatiquement à partir de la donnée d’un patron abîmé, nous sommes à même de cibler des fragments de modèle. Ces requêtes suivent un algorithme de détection basé sur des concordances structurelles. Les fragments ainsi détectés peuvent être, après un dialogue avec le concepteur, remplacés par les contextualisations des patrons de conception adéquats.

Un patron abîmé a le même niveau de généricité qu’un patron de conception et représente donc une famille génératrice de solutions alternatives à un type de problème dont un patron de conception propose la meilleure solution. Ces solutions alternatives sont structurellement différentes et présentent moins d’avantages, en termes de bonnes pratiques, que la solution optimale préconisée par le patron. Nous avons caractérisé les solutions alternatives par l’ensemble des points forts qu’elles dégradent. Les points forts d’un patron de conception expriment les critères d’architecture et les facteurs de qualité logicielle apportés par son utilisation. Ces critères explicitent en quoi un patron de conception constitue la meilleure solution pour un type de problème, et nous permettent de classifier les patrons abîmés selon leur degré de dégradation.

L’intégralité des patrons abîmés que nous avons identifiés sont issus de la décontextualisation de solutions alternatives collectées auprès de concepteurs particuliers. Ces derniers ont été choisis pour leurs connaissances académiques en modélisation par objets, n’incluant pas, au temps de la collecte, les patrons de conception. Nous avons ainsi obtenu un large éventail de solutions alternatives. Nous disposons alors d’une base de patrons abîmés pouvant être utilisée en complément du GoF, constituant ainsi un catalogue de mauvaises pratiques de conception.

Afin d’identifier les fragments de modèles caractéristiques de ces mauvaises pratiques de conception, nous avons développé un algorithme capable de détecter toutes les contextualisations de patrons abîmés. Cet algorithme recherche exactement un patron abîmé en autorisant des classes supplémentaires structurellement concordantes à l’architecture du patron abîmé. Grâce à des filtrages successifs, cet algorithme est rapide et efficace. De plus il est capable de gérer les relations interdites et facultatives entre les classes des fragments. En utilisant un profil UML, nous avons complété la description des patrons abîmés afin de générer de manière automatique les requêtes de détection. Ainsi, tout nouveau patron abîmé ajouté à notre base devient immédiatement détectable.

Nous avons également conçu et outillé une activité de revue de conception, au même titre qu’il existe des activités de revue de code. Cette activité analyse le modèle d’un concepteur, cherche les fragments caractéristiques, et le cas échant, les transforme pour y intégrer un patron de conception. De par le dialogue que notre outil établit avec le concepteur, ce dernier peut gérer de manière semi-automatique le déroulement de l’activité tout en ayant conscience des qualités supplémentaires apportées à son modèle. Notre outil peut être déployé dans tout processus où les modèles jouent un rôle prépondérant.