userM1 : définition d’un modèle

Pour définir le modèle présenté à la Figure8.12(b), userM1 clique sur le bouton com- posant, le DrawingArea enregistre l’élément composant du DSML de userM2 encapsulé dans ce bouton comme élément courant. Lorsque userM1 clique dans la zone de dessin, le DrawingArearécupère la référence de l’élément courant vers l’interface concreteItf qui dans ce cas est componentSC. Le DrawingArea appelle ensuite la méthode isModelLink() de componentSC qui retourne false. Le DrawingArea va examiner l’élément courant pour savoir si userM2 a assigné une représentation graphique à cet élément (avec l’éditeur de dessin) ou s’il faut appeler getModelRepresentation() pour obtenir la représentation par défaut de componentSC. Dans notre cas, userM2 a assigné une représentation graphique. Le DrawingArea récupère alors le JPanel qui contient cette représentation et l’affiche dans la zone de dessin. Le DrawingArea récupère ensuite la référence de l’élément courant vers l’interface SemanticItf du composant M1Semantic. Il appelle la méthode validateCreation que userM3 a implantée de telle sorte qu’elle retourne toujours true et donc autorise tou- jours la création de la nouvelle instance de composant.

Pour créer les deux instances du connecteur service, userM1 clique sur le bouton ser- vice et procède de la même façon que pour créer une instance de composant.

Pour relier les deux instances de connector créées à l’instance de component, userM1 clique sur le bouton agregation. Le DrawingArea enregistre l’élément agregation du DSML de userM2 comme l’élément courant. Lorsque userM1 clique dans la zone de dessin le DrawingArea récupère la référence de l’élément courant agregation vers l’in- terface concreteItf qui dans ce cas est AgregationSC. Le DrawingArea appelle ensuite la méthode isModelLink() de AgregationSC qui retourne true. Il vérifie que userM1 a bien cliqué sur un élément dans la zone de dessin, et attend le 2e clic de userM1. Après le 2e clic de userM1, le DrawingArea récupère la référence de l’élément courant vers l’inter- face SemanticItf du composant M1Semantic. Il appelle la méthode isConnectable de cette interface qui va vérifier que les deux éléments sur lesquels userM1 a cliqué sont bien de type composant pour l’un et service pour l’autre. Si oui elle retourne true et donc autorise la liaison. Lorsque la liaison est autorisée, le DrawingArea crée un nouvel élément liaison de type agregation, enregistre la source et la destination de cette liaison comme étant les deux éléments sur lesquels userM1 a cliqué. Puis DrawingArea appelle la méthode com- puteModelClosestBorderde AgregationSC qui cherche les deux points de connexion les plus proches sur les représentations graphiques de la source et de la cible de la liaison. Cette méthode va assigner les mêmes coordonnées dans la zone de dessin à ces points de connexion ce qui aura pour effet visuel de coller l’élément de type service à l’élément de type composant. Le DrawingArea appelle ensuite la méthode getModelLinkRepresen- tationde AgregationSC qui ne retourne rien parce que userM3 n’a pas implanté une re- présentation par défaut pour l’agregation au niveau M1. Enfin, pour créer le 2e élément serviceet le coller sur l’élément component, userM1 procède de la même façon que pour le premier et obtiens au final le modèle présenté à la Figure8.12(b).

Avec le déroulement de ce fil d’exécution, on peut constater la totale indépendance entre la partie générique de GyTUNe et la partie spécifique. La partie spécifique implan-

tée par les userM3 peut évoluer et être adaptée sans que cela influe sur le comportement de la partie générique. Tant que les contrats entre les deux parties sont bien respectés c’est-à-dire que les composants définis dans la partie spécifique fournissent bien les inter- faces ConcreteItf et SemanticItf alors la partie générique pourra créer un environnement de méta-modélisation et le spécialiser en fonction des services que lui fournit la partie spécifique.

Chapitre 9

Validation

9.1

Introduction

Notre objectif initial était d’être en mesure d’implanter des DSML pour la définition des politiques d’administration dans TUNe. Ces DSML pour TUNe sont tous dans le do- maine des langages à composants.

Pour montrer la généricité de GyTUNe, nous allons présenter deux cas d’utilisation dans deux domaines différents. Le premier domaine est un domaine technique dit horizontal, il s’agit du domaine des composants. Nous allons utiliser GyTUNe pour créer un environ- nement de méta-modélisation dédié aux architectures à composants et nous montrerons comment implanter deux DSML de TUNe dans ce domaine. Le deuxième cas d’utili- sation concernera un domaine métier dit vertical, il s’agit du domaine de la gestion de projets. Nous allons utiliser GyTUNe pour créer un environnement de méta-modélisation permettant de créer des DSMLs pour la construction de diagrammes temporels et nous montrerons comment implanter deux DSML dans ce domaine (Diagrammes de GANTT et de PERT utilisés par les responsables de projets).

Premièrement, nous allons présenter chaque domaine et les spécificités qu’un outil de méta-modélisation qui lui serait dédié devrait prendre en compte. Deuxièmement, nous présenterons, comment ces spécificités ont été implantées, et enfin nous présentons les environnements de méta-modélisation obtenus avec pour chacun des exemples de DSMLs créés.