Pour conclure, les deux implémentations, le DSL Xtend et ATLC, permettent le dévelop-pement de transformations générant des ensembles de modèles explorables. Les deux DSL partagent des concepts similaires dans l’approche, mais varient significativement dans l’implé-mentation. Il en va de même pour les capacités de ces deux implémentations. Le Tableau 6.1 compare les deux implémentations sur différents points.
DSL Xtend ATLC
Type de DSL Interne Externe
Implémentation API Compilateur
Modèle de contraintes Spécialisé Générique
Solveurs disponibles Cassowary Cassowary, Choco, MiniCP, xcsp3 Collaboration entre solveurs Non Manuelle
Définition des interacteurs Impérative Impérative Couches d’abstraction Géométrique Non3
Réécritures de contraintes Manuelle Manuelle / Transformation de modèles Couplage cible / contraintes Faible Fort
TABLE6.1 – Tableau comparatif des caractéristiques des deux implémentations
ATLC a été conçu après le DSL Xtend, c’est pourquoi il ajoute globalement de nouvelles fonctionnalités telles que le support de plusieurs solveurs. La gestion des contraintes est amé-liorée avec ATLC. En effet, avec le DSL Xtend, il n’est pas possible de récupérer les liens de traçabilité entre un élément source et les contraintes correspondantes. Par conséquent, il est difficile, lors de la suppression d’un élément source, de supprimer les contraintes correspon-dantes. Alors qu’en ATLC les contraintes sont complètement intégrées dans la transformation et sont des éléments cibles comme les autres. La traçabilité est alors automatiquement gérée par la transformation et la suppression des contraintes liées à un élément source est possible. Le seul avantage du DSL Xtend sur ATLC est la possibilité d’utiliser une couche d’abs-traction géométrique facilitant ainsi l’expression des contraintes pour des utilisateurs non
6.3. Comparaison entre le DSL Xtend et ATLC
périmentés. C’est pourquoi nous avons prévu d’ajouter des couches d’abstractions à ATLC. De plus, nous souhaitons mettre en place une structure générique pour pouvoir, par la suite, intégrer facilement d’autres couches d’abstraction.
CHAPITRE7
C
AS D
’
ÉTUDE
Dans les chapitres précédents, nous avons présenté notre approche permettant l’explora-tion d’ensembles de modèles. Nous avons notamment présenté la méthode que nous avons mise en place pour résoudre ce problème et les langages que nous avons développés pour mettre en place cette méthode automatiquement.
Dans les sections suivantes, nous présenterons plusieurs cas d’étude développés durant la thèse pour explorer différents aspects des langages de transformation proposés. Avant de présenter les différents cas d’étude, nous introduirons, dans la section 7.1, le métamodèle de diagrammes utilisé dans toutes les transformations suivantes. Ensuite, dans la section 7.3, nous présenterons un visualiseur de diagrammes de séquence développé avec le DSL interne à Xtend. Puis, dans la section 7.2, nous présenterons trois visualiseurs de diagrammes UML développés, toujours avec le DSL Xtend, par quatre étudiants de l’ESEO dans le cadre de leur projet de fin d’études. Dans la section 7.4, nous détaillerons un visualiseur de planning, développé en ATLC, dans lequel plusieurs solveurs collaborent. Enfin, dans la section 7.5 nous présenterons un éditeur permettant de manipuler un diagramme de classes et d’objets dans une même fenêtre. Cet éditeur sert de cas d’étude d’un article d’atelier international [Le +19d].
7.1 L’exploration de modèles appliquée aux diagrammes
Les diagrammes que nous allons présenter sont composés de formes géométriques simples. Par souci de simplicité, nous ne considérons que les formes simples telles que le rectangle, la ligne, la flèche (avec différentes têtes), le texte ou le cercle. La Figure 7.1 donne une version simplifiée du métamodèle de diagramme que nous utilisons. Ce métamodèle simplifié de vue est inspiré de JavaFX1, une bibliothèque Java permettant de développer des interfaces gra-phiques. Comme JavaFX, ce métamodèle contient des éléments graphiques simples pouvant être affichés sur un écran.
Il y a plusieurs classes représentant des formes primitives, telles que le Rectangle, le Circle ou la Line. D’autres représentent différents types de flèches, Arrow, DiamondArrow, GeneralizationArrowetAggregationArrow. La classeTextpermet d’afficher du texte. Enfin, ActorFX représente une personne stylisée, cet élément est notamment utilisé dans le dia-gramme de cas d’utilisation. Cette dernière forme pourrait être composée d’un cercle et de
Rectangle x : double y : double width : double height : double Line startX : double endX : double startY : double endY : double Text x : double y : double /width : double /height : double text : String Arrow fromX : double fromY : double toX : double toY : double
DiamondArrow GeneralizationArrow AggregationArrow ActorFX x : double y : double width : double height : double Circle radius : double centerX : double centerY : double
FIGURE7.1 – Métamodèle de diagrammes simplifié
lignes mais sert ici à montrer comment une forme définie par l’utilisateur peut être réutilisée. Ces classes se regroupent en plusieurs catégories.
Les classes Rectangle,Text etActorFX se comportent toutes comme des rectangles au sens géométrique du terme. Elles possèdent quatre propriétésx,y,widthetheightdécrivant respectivement la position et les dimensions du rectangle. Pour l’ActorFX, ce rectangle cor-respond à un rectangle invisible dans lequel la figure humaine est contenue. Pour leText, les propriétéswidthetheightne sont accessibles qu’en lecture seule, car elles sont calculées à partir des dimensions dutextà afficher et de la police utilisée.
LeCirclereprésente un cercle et possède trois propriétés : unradiuspour son rayon et deux coordonnéesxetypour son centre. LaLinereprésente une ligne et possède quatre pro-priétés, deux coordonnées pour chaque extrémité de la ligne (startX,startY,endXetendY). Les classes Arrow, DiamondArrow, GeneralizationArrow et AggregationArrow possèdent, elles aussi, quatre propriétés, deux coordonnées pour chaque extrémité de la flèche (fromX, fromY,toXettoY).
Ce métamodèle minimaliste n’est pas spécifique à un diagramme en particulier, mais peut servir pour en représenter une multitude. De plus, lorsque les diagrammes le nécessitent, il est possible d’ajouter des éléments dédiés (l’ActorFXpar exemple).
Period 1 (5.0) Period 2 (6.0) Period 3 (7.0)
001
002
003
FIGURE7.2 – Un diagramme conforme au métamodèle montré dans la Figure 7.1
Period 1 (5.0) Period 2 (6.0) Period 3 (7.0)
001
002
003
FIGURE 7.3 – Un diagramme conforme et va-lide
7.1. L’exploration de modèles appliquée aux diagrammes
Ce métamodèle permet de représenter des figures géométriques, mais ne permet pas, par construction, d’assurer la validité d’un diagramme. En effet, chaque diagramme possède ses propres règles de construction qui spécifient notamment les positions possibles des éléments les uns par rapport aux autres. Par exemple, considérons un diagramme représentant un plan-ning, des tâches doivent être affectées à des périodes. La Figure 7.3 montre un diagramme valide, chaque tâche est représentée par un rectangle contenant son identifiant, les rectangles correspondant aux tâches sont contenus dans les rectangles correspondant aux périodes et les liens de dépendance entre les tâches sont représentés par des flèches. Dans la Figure 7.2, les formes présentes ne forment pas un diagramme valide. Bien que les deux figures soient composées d’éléments graphiques respectant le métamodèle présenté dans la Figure 7.1 une seule des deux est valide quand on la considère comme un diagramme.
Pour être valide, un diagramme doit, en plus d’être conforme à un métamodèle de formes géométriques, respecter un ensemble de règles de construction imposées par la syntaxe gra-phique du diagramme en question. Ces règles sont spécifiques à chaque type de diagramme. Par exemple, le diagramme de la Figure 7.3 est valide, tandis que celui de la Figure 7.2 ne l’est pas.
Ainsi, les diagrammes valides forment un sous-ensemble des images composées de fi-gures géométriques, ou, en d’autres termes, les diagrammes valides forment un ensemble de modèles, quand on considère l’espace des modèles formé par toutes les figures géomé-triques conformes au métamodèle présenté dans la Figure 7.1 et les règles de construction (ou contraintes) imposées par la syntaxe graphique du diagramme considéré. Il est donc pos-sible d’utiliser notre approche pour :
1. Spécifier déclarativement la transformation permettant la visualisation, sous la forme d’un diagramme, d’un métamodèle quelconque.
2. Explorer l’ensemble des diagrammes valides correspondant à un modèle conforme au métamodèle source.
Dans le cas des diagrammes, l’exploration de l’ensemble des modèles peut impliquer plu-sieurs types de réparations. Le premier type de réparation, le plus simple, n’impacte que la vue, par exemple, sur le diagramme de la Figure 7.3, l’utilisateur déplace le rectangle corres-pondant à la tâche003dans le rectangle correspondant à la période3. Dans ce cas, le solveur se contente de calculer les nouvelles positions des extrémités des flèches partant de la tâche 003de façon à ce qu’elles soient toujours contenues dans le rectangle correspondant à la tâche 003.
Le second type de réparation envisageable implique une mise à jour du modèle source. Par exemple, toujours sur le diagramme de la Figure 7.3, imaginons que l’utilisateur déplace le rectangle correspondant à la tâche002dans le rectangle correspondant à la période1. Dans ce cas là, le changement est appliqué au modèle source, ici, changer l’affectation de la tâche 002de la période2à la période1. Ensuite, le moteur d’exécution de transformation de modèles incrémentale propage le changement jusqu’à la vue.
On définit un interacteur comme le système responsable de la capture des évènements, clavier et souris, produits par l’utilisateur et de l’application des modifications si nécessaire. Par exemple, dans le diagramme de la Figure 7.3, lorsque l’utilisateur clique sur un rectangle correspondant à une tâche et le déplace, c’est l’interacteur qui analyse le déplacement de la figure (simple déplacement du rectangle ou changement de période ?) et applique les change-ments nécessaires (mise à jour des coordonnées du rectangle pour un simple déplacement, ou changement de période sinon). Bien qu’intéressants, ces interacteurs sont au-delà du cadre de cette thèse et nous avons décidé de ne pas les intégrer aux langages développés. En effet, bien que pratiques pour définir comment l’utilisateur peut interagir avec une interface graphique, ces interacteurs ne sont pas directement liés à notre approche. C’est pourquoi, dans les différents exemples de visualiseurs de diagrammes suivants, le code des interacteurs est écrit en Xtend impératif.
De plus, ces démonstrateurs ont été implémentés dans l’objectif de montrer la pertinence de l’approche et non dans le but de concevoir des outils capables de remplacer des éditeurs de diagrammes professionnels.