Acceleo 2.6 : Tutoriel architecte. Page 1/75

Transcription

1 Page 1/75

2 Page 2/75 ACCELEO Tutoriel Architecte Ce manuel est la propriété exclusive de ses auteurs et a été concédé par ces derniers au profit de la société OBEO, SARL au capital de dont le siège social est sis 2 rue Robert Schuman, Rezé, inscrite au Registre du Commerce et des sociétés de NANTES sous le numéro Ce manuel est protégé au titre des dispositions légales et réglementaires régissant les droits de propriété intellectuelle. Il traite d un produit logiciel dénommé ACCELEO, actuellement distribué sous licence open source EPL par la société OBEO. Ce manuel a été fait avec la plus grande attention. Toutefois, des erreurs ont pu se glisser dans la version de ce manuel. OBEO ne peut être, en aucun cas, tenue pour responsable des suites que ces erreurs pourraient entraîner. La distribution de ce manuel n est pas libre. Ce manuel peut-être téléchargé gratuitement après enregistrement sur le site de la société OBEO, et peut-être consulté dans le cadre d'une utilisation commerciale ou non de la technologie ACCELEO. Cependant, la copie, la traduction et la redistribution de ce document sur support électronique ou sur papier nécessite une autorisation de la part de OBEO. Nous rappelons à votre attention que les dispositions légales régissant les conditions d utilisation et de distribution de ce manuel sont regroupées au sein du Code de la Propriété Intellectuelle, notamment dans son Titre II Droits des auteurs (Articles L121-1 à L123-12). Nous nous réservons le droit de modifier sans avis préalable ce manuel ou le produit. Merci de respecter ces dispositions. «OBEO», «ACCELEO», ainsi que les logos OBEO et ACCELEO associés à ce manuel sont déposés par OBEO SARL en France et/ou dans d'autres pays du monde. Tous les autres noms, titres, dessins, et logos sont la propriété exclusive de leurs auteurs respectifs et sont protégés au titre des droits de propriété intellectuelle. Ce manuel a été rédigé avec les outils suivants : OpenOffice Auteurs : Jonathan MUSSET, Etienne JULIOT, Stéphane LACRAMPE avec la participation de : Goulwen LE FUR, Julien DUPONT, Guillaume RAIMBAULT, Nathalie LEPINE, William PIERS et Cédric BRUN Copyright Obeo. Tous droits réservés

3 Page 3/75 Sommaire 1 - Introduction Installation Préparation Scénario 1 : générateur simple XHTML Création du prototype Structure du projet prototype Page prototype Création du générateur Projet du générateur Création du générateur Du prototype au générateur : utilisation de l'éditeur réflectif Utilisation des données du modèle dans le générateur Création de la chaîne d'exécution Scénario 2 : générateur de classe de base Java Création du prototype Structure du projet prototype Classe Java prototype Création du générateur de base Structure du projet générateur Du prototype au générateur Adaptation du prototype Correction de formatage Création puis utilisation de services Sélection des fichiers à générer Stéréotypes dans le modèle Service «hasstereotype» Filtre des classes à l'aide du service «hasstereotype» Création du fichier d'exécution Amélioration du générateur Gestion des opérations Génération incrémentale Usage des balises de code utilisateur Gestion de l'héritage Constructeur paramétré Scénario 3 : personnalisation du module d'exemple JSP/JDBC Installation et test du module JSP/JDBC...44

4 Page 4/ Récupération et installation du module sur le site Acceleo.org Analyse de l'existant du module Générateur de pages JSP Générateur de la page de navigation Génération d'actions Configuration de l'application web fichier «web.xml» Classes de transfert de données Classes d'accès aux données Résultat de la génération du module Personnalisation du module Ajout d'un générateur SQL Nouveau fichier générateur Générateur SQL Modification de la chaîne d'exécution Configuration de la génération fichiers «properties» Création du fichier «properties» par défaut Adaptation des générateurs Agilité de la méthode reconfiguration de la génération Scénario 4 : Méta-modèle spécifique création et usage Création d'un méta-modèle Projet de méta-modèle Création du méta-modèle Création de l'éditeur de modèles Création d'un modèle conforme au méta-modèle de cinématique Générateur d'écrans XHTML Chaîne de génération Les mêmes possibilités avec les méta-modèles...75

5 Page 5/ Introduction Ce document est un tutoriel détaillé permettant aux architectes et développeurs de créer des modules de génération de code pour Acceleo, produit initié par la société Obeo. Les fonctionnalités abordées permettront la prise en main de l'environnement d'édition, et de test des templates Acceleo. Ce générateur de code est dédié aux personnes qui veulent tirer profit des technologies MDA pour accroître la productivité de leurs développements informatiques. Il permet de générer des fichiers à partir de modèles UML, MOF, EMF... Il s'agit d'un plugin caractérisé par : Son intégration complète à l'environnement Eclipse et au framework EMF La gestion de la synchronisation entre le code et le modèle La génération incrémentale La simplicité d'adaptation à tout type de cible technique La facilité de mise au point et de maintenabilité des templates La colorisation syntaxique, la complétion, la détection d'erreurs Ce présent guide ne se veut pas être une formation pour l'ensemble des problématiques couvertes par le MDA et Acceleo en particulier. Ainsi, la lecture de ce guide nécessite les prérequis suivants : Java modélisation (par exemple : UML) utilisation d'eclipse La connaissance des concepts suivants sera également un plus, mais ne sera pas indispensable à la lecture de cette documentation : méta-modèles méta-modèle UML2 développement de plugins Eclipse MDA ou MDD Ce tutoriel s'inscrit dans un ensemble de documentations proposées par la société Obeo. Chaque documentation aborde une facette différente de la maîtrise d'acceleo : référence : inventaire et explication de chaque service et chaque élément de syntaxe guide utilisateur : documentation des fonctionnalités d'acceleo tutoriel utilisateur : guide pour la mise en oeuvre dans des projets cibles de générateurs

6 Page 6/ Installation Pour installer Acceleo, il faut commencer par télécharger et installer la plateforme Eclipse 3.2.2, EMF 2.2.2, et UML Il faut ensuite télécharger et installer Acceleo 2.5. Plusieurs procédures existent pour l'installation d'acceleo sur chaque poste utilisateur. Chaque procédure a ses spécificités, fonction du contexte de déploiement de la plateforme Eclipse. Le mode d'installation conseillé est l'installation à partir du site de mise à jour Chaque type d'installation est détaillé pas à pas dans le guide utilisateur.

7 Page 7/ Préparation Cette partie vise à initialiser l'environnement Eclipse afin de pouvoir exécuter ces tutoriels dans des conditions identiques. Figure 3.1: Changement de perspective Eclipse Après avoir installé le plugin Acceleo, lancer l'ide Eclipse. Ouvrir le menu «Window» puis sélectionner le menu «Open Perspective > Other..»(cf figure 3.1). La fenêtre de la figure 3.2 s'ouvre. Sélectionner la perspective Acceleo puis cliquer sur Ok. Figure 3.2: Sélection perspective Acceleo de la Eclipse réorganise les vues et onglets qui le composent et la perspective Acceleo est initialisée ; cet état est confirmé par la présence de l'icône «Acceleo» à l'emplacement de la perspective active au dessus de l'onglet «Outline» d'eclipse (cf figure 3.3). Figure 3.3: La perspective Acceleo

8 Page 8/ Scénario 1 : générateur simple XHTML Le premier scénario sur lequel ce tutoriel s'appuie est la création d'un générateur capable de produire de la documentation à partir d'un modèle UML2. Une page de documentation sera créée pour chaque classe du modèle rencontrée et elle décrira les attributs et quelques informations supplémentaires de l'entité. Un exemple du résultat est donné par la figure 4.1. Figure 4.1: Page documentant la classe ArticleDeBlog Obeo préconise l'approche «bottom-up» pour la réalisation de modules MDA. Celle-ci sera utilisée dans les scénarios de cette documentation. La méthode consiste à produire en premier lieu un prototype de la cible de génération afin de définir des patrons pour les générateurs. La seconde étape vise à s'appuyer sur le prototype opérationnel et validé afin de produire les générateurs permettant d'arriver à ce résultat. Les générateurs peuvent alors être appliqués sur les modèles définitifs. La première étape de ce scénario est donc de réaliser un prototype permettant de définir la cible de génération. Pour notre exemple, nous allons créer une page XHTML qui fixera le contenu final des fichiers à générer. Remarque : La connaissance du langage XHTML n'est en aucun cas nécessaire pour la compréhension de ce scénario, le choix pour se langage réside dans sa simplicité de mise en oeuvre et les quelques connaissances utiles seront données au cours de ce tutoriel.

9 Page 9/ Création du prototype Structure du projet prototype La première étape consiste à créer une page XHTML décrivant une classe UML. Pour cela, il faut ouvrir Eclipse et créer un nouveau projet simple : «File > New > Project...» puis «General > Project», renseigner le nom du projet dans l'assistant et cliquer sur «Finish» (cf figure 4.2). Dans ce tutoriel, le projet cible de génération sera nommé «fr.obeo.sample.obeo.weblog.xhtml» mais ce nom n'impacte pas la suite de ce tutoriel. Figure 4.2: Création d'un nouveau projet Java Puis créer un répertoire pour stocker les pages XHTML : Clic droit sur le projet puis «New > Folder», entrer le nom «WebContent» dans l'assistant de création de répertoire, et cliquer sur «Finish» (cf figure 4.3). Figure 4.3: Création d'un nouveau répertoire

10 Page 10/ Page prototype Pour créer la page prototype, il faut d'abord effectuer un clic droit sur le répertoire «WebContent» puis sélectionner «New > File», remplir le champ «File name» avec «example.html», et cliquer sur «Finish» (cf figure 4.4). Figure 4.4: Création du fichier exemple Un fichier «example.html» est créé dans le répertoire «WebContent» du projet. Remarque : Il est possible que Eclipse embarque un navigateur intégré. Si tel est le cas après la création du fichier «example.html», il ouvrira le fichier avec son navigateur dans un nouvel onglet qu'il est conseillé de fermer. Il faut maintenant définir le contenu d'une page type obtenue par notre générateur. L'objectif étant de décrire des classes UML, la page contiendra deux blocs (comme sur la figure 4.5) : un bloc contenant quelques informations sur la classe (nom et commentaires éventuels) ; un bloc contenant la liste de tous les attributs de la classe (nom et type). Figure 4.5: Les deux blocs d'information

11 Page 11/75 Il faut désormais insérer le code source ci-dessous dans le fichier «example.html», en l'ouvrant à l'aide d'un clic droit, «Open with > Text editor». <html> <head/> <body> <h1>class Description</h1> <p>name of class : ArticleDeBlog</p> <p>comment : </p> <h1>attributes</h1> <ul> <li>titre : String</li> <li>datecreation : Date</li> <li>contenu : String</li> <li>auteur : Utilisateur</li> </ul> </body> </html> Remarque : Afin d'être en parfaite conformité avec le standard XHTML du W3C, il faudrait faire référence à la DTD de ce standard ainsi que définir les espaces de nommage dans la balise <html>. Mais par soucis de simplicité, le code de ces deux points a été omis. Quelques éléments de compréhension XHTML : Le XHTML est un langage à balises utilisé pour créer des pages web statiques. Il est inspiré du HTML mais respecte le formalisme XML (toute balise ouverte doit être fermée). Voici la signification des balises utilisées dans l'exemple : 1. <html> début de la page web 2. <head /> balise pouvant spécifier des informations supplémentaires, inutile dans cet exemple 3. <body> début du contenu de la page 4. <h1>... </h1> balise délimitant un texte titre. L'affichage du titre sera par défaut en gras et dans une taille de police plus large 5. <p>... </p> balise délimitant un paragraphe 6. <ul> début de liste 7. <li>... </li> ligne de liste 8. </ul> fin de liste 9. </body> fin du contenu de la page 10. </html> fin de la page Ce paragraphe tend à compléter la compréhension de l'exemple. La maîtrise du langage XHTML n'est cependant absolument pas un frein à la poursuite de ce tutoriel. Le rendu est similaire à la figure 4.6 quand on ouvre cette page avec le navigateur web du système d'exploitation (clic droit sur le fichier «example.html» puis «Open with > System editor»).

12 Page 12/75 Figure 4.6: Le fichier prototype ouvert avec un navigateur web Cette page décrit une classe, «ArticleDeBlog», n'ayant pas de commentaire et possédant quatre attributs (titre, datecreation, contenu et auteur) de divers types (String, Date...). Ce fichier constitue le prototype de la cible de génération (toutes les pages étant de la même forme). Ce prototype mis au point, l'étape suivante consiste en la création du générateur permettant d'arriver à ce résultat.

13 Page 13/ Création du générateur Acceleo est basé sur un système de template qui favorise particulièrement l'approche de développement par prototype. En effet, une fois le prototype mis au point, il sert d'axe principal pour la réalisation des générateurs. Cette démarche est décrite dans cette partie Projet du générateur Dans un premier temps, il faut créer un projet de génération Acceleo : exécuter «File > New > Generator Project» (cf figure 4.7). Pour ce tutoriel, le projet est nommé «fr.obeo.pim.uml2.gen.xhtml», cette convention décrit le fait que le module est réalisé par la société Obeo, que le méta-modèle d'entrée est UML2 et qu'il permet la génération de fichiers XHTML. Il est conseillé dans le cadre de la réalisation de nombreux projets d'adopter une convention similaire afin de structurer son outillage MDA. Figure 4.7: Création d'un nouveau projet de génération dans la perspective Acceleo Le nouveau projet apparaît dans l'explorateur de package et un petit décorateur «Acceleo» indique qu'il s'agit d'un projet de génération (cf figure 4.8). Figure 4.8: Projet génération Acceleo de

14 Page 14/ Création du générateur Il faut désormais créer le fichier du générateur à l'aide du menu «File > New > Empty Generator», après avoir sélectionné le répertoire «src» dans l'explorateur de package. Ceci lance un assistant en deux étapes. Dans la première étape, il faut renseigner le type du méta-modèle d'entrée et le type racine du template. Le méta-modèle dans notre cas est UML2 qui a pour URI1 au sein d'eclipse « Le type racine du template est le type d'objet qui va provoquer la génération d'un fichier lors de son exécution. En l'occurrence, un fichier XHTML sera généré pour chaque classe dans le modèle UML, le type racine de ce template est donc «uml2.class» (cf figure 4.9). Figure 4.9: Générateur - sélection du métamodèle et du type racine Dans la seconde étape, il faut vérifier le répertoire et donner le nom «xhtml.mt» au générateur. La page devrait ressembler à la figure Figure 4.10: Générateur - Répertoire et nom du générateur 1 L'URI d'un métamodèle est un identifiant unique permettant de faire référence à celui-ci lors de la création d'outils ou de modèles conformes à celui-ci

15 Page 15/75 Cliquer sur «Finish» pour lancer la création du générateur. Double-cliquer sur le fichier «xhtml.mt» dans le répertoire «src» pour afficher le contenu du template (cf figure 4.11). Lors de la création d'un générateur vide («Empty Generator»), seul le méta-modèle et le premier script (portant le nom du générateur et du type rentré dans la première étape de l'assistant) sont définis. Il faut créer le corps du template pour obtenir le résultat souhaité. Figure 4.11: Template généré par l'assistant Du prototype au générateur : utilisation de l'éditeur réflectif Pour le contenu du générateur, il faut repartir du prototype réalisé dans la première partie de ce tutoriel, copier le code du fichier «example.html» et le coller à la suite de la balise script du générateur construit par défaut. Le nom par défaut de l'attribut «file» doit être changé en <%name%>.html (cf figure 4.12). Cet attribut permet de fixer le format du nom des fichiers qui seront générés. En y définissant la valeur <%name %>.html, les fichiers auront un nom calculé à partir du nom de la classe (<%name%>) et de l'extension «.html». Figure 4.12: Générateur modifié à l'aide du prototype Le template ainsi défini est capable de générer des fichiers depuis un modèle UML2. Acceleo apporte un éditeur pour pré-visualiser le résultat de la génération : l'éditeur réflectif. Pour ouvrir cet éditeur, il faut sélectionner le modèle sur lequel le générateur s'applique. Dans ce tutoriel, le modèle «WebLog_fr.uml» est utilisé, la récupération de celui-ci peut se faire sur le site d'acceleo dans la

16 Page 16/75 rubrique «Documentation > Prise en main» : Le fichier est disponible via un hyperlien dans la section «Export XMI». Dans un premier temps, il faut créer un nouveau répertoire «model» pour y déposer les modèles : se placer dans le projet créé dans la première partie de ce scénario, effectuer un clic droit, sélectionner «New > Folder», entrer «model» dans le champ «Folder name» et cliquer sur «Finish». Le site fourni donc le modèle à intégrer dans ce nouveau répertoire. Il faut le télécharger dans le système de fichiers, puis sous Eclipse, ouvrir le menu «File» et cliquer sur «Refresh» afin de le faire apparaître dans les ressources disponibles. Figure 4.13: Récupération du modèle WebLog_fr sur le site Acceleo Une fois le modèle importé dans le workspace Eclipse, il est possible d'utiliser l'éditeur réflectif Acceleo : effectuer un clic droit sur le fichier «model/weblog_fr.uml» et lancer le menu «Open with > Acceleo Reflective Editor». Un nouvel onglet s'ouvre, détaillant le modèle «WebLog_fr» sous forme arborescente avec des packages, des classes, des associations... (cf figure 4.14). Figure 4.14: L'éditeur réflectif Acceleo Afin de pouvoir pré-visualiser le résultat de la génération, il faut préciser le générateur que l'éditeur doit utiliser : effectuer un clic droit dans la fenêtre de l'éditeur réflectif (la cible du clic n'est pas importante) et lancer le menu «Acceleo > Select Template». Une fenêtre s'affiche avec tous les projets contenant des générateurs Acceleo, il reste à sélectionner le générateur «xhtml.mt» dans le projet de génération XHTML (cf figure 4.15) et cliquer sur «OK».

17 Page 17/75 Figure 4.15: Sélection du générateur XHTML Une fois le générateur sélectionné, les objets du modèle concernés par le générateur sont marqués par un icône permettant de les repérer facilement (cf figure 4.16). Figure 4.16: Marquage des objets concernés par le générateur Le résultat de la génération peut être consulté en sélectionnant l'un de ces objets et en cliquant sur l'onglet «Source». Ainsi, si la classe «ArticleDeBlog» est sélectionnée, l'onglet «Source» affichera le code donné par la figure Figure 4.17: Premier résultat de l'éditeur réflectif Le résultat est bien un fichier XHTML donnant des informations sur la classe. Le même résultat sera obtenu en sélectionnant une autre classe du modèle, car pour le moment, toutes les informations sont statiques dans le générateur. Il faut le compléter pour obtenir les informations de manière dynamique.

18 Page 18/ Utilisation des données du modèle dans le générateur La première information à obtenir est le nom de la classe à l'origine du fichier. Dans le méta-modèle UML2, une classe a un attribut «name» qui correspond au nom de la classe. Ceci va être utilisé dans le générateur pour obtenir l'information recherchée. Chaque occurrence du mot «ArticleDeBlog» va être remplacée, dans le fichier «xhtml.mt», par l'instruction «<%name%>» comme indiqué sur la figure Figure 4.18: Récupération du nom de la classe La modification effectuée au template a évidemment des impacts sur le résultat de la génération. Dans l'éditeur réflectif, un simple clic droit sur le menu «Acceleo > Reload Template» permet de rafraîchir le calcul du résultat de la génération. Il est inchangé pour la classe «ArticleDeBlog» mais le nom est bien mis à jour pour d'autres classes. Par exemple, pour «Utilisateur» le résultat est similaire à celui de la figure Figure 4.19: Le résultat de la génération avec le nom de la classe dynamique

19 Page 19/75 Remarque : En dé-sélectionnant le texte du code généré, l'éditeur marque en violet le code généré statiquement et en noir le code généré dynamiquement. Ainsi, dans la figure 4.19 le nom de la classe «Utilisateur» du modèle est en noir, contrairement au reste du texte qui est en violet car obtenu statiquement. De manière analogue, il est possible d'obtenir les commentaires de la classe à l'aide de l'instruction < %ownedcomment%>. En l'ajoutant à la suite du texte «Comment :», le premier bloc est entièrement renseigné dynamiquement. Il faut maintenant définir la partie du générateur qui permet de lister les attributs. Étant donné que le nombre d'attributs dans une classe n'est pas fixe, il faut utiliser une boucle pour créer la liste de manière dynamique. Dans la syntaxe Acceleo, l'instruction «for» permet de boucler sur les entités du modèle. Son utilisation est la suivante : <%for (listeelements) {%> Texte à générer pour chaque élément <%}%> Le générateur sera ainsi en mesure de créer du texte pour chaque attribut d'une classe. Pour ce tutoriel, l'objectif est de générer une liste XHTML avec une entrée par attribut. Il faut donc créer une boucle qui générera une ligne par attribut en donnant leur nom et leur type à chaque fois. <%for (attribute) {%> <li>nom type</li> <%}%> Pour chaque attribut, une ligne commençant par <li> et finissant par </li> est créée. Il ne reste plus qu'à obtenir le nom et le type des attributs. En UML2, ils possèdent les informations «name» et «type» mais un problème de contexte se pose. En effet, le script courant s'applique sur le type «Class», mais c'est le nom et le type des attributs qui sont attendus. C'est pourquoi Acceleo transfert son contexte lorsqu'il effectue une boucle, l'utilisation des instructions <%name%> et <%type%> portera bien sur les attributs de la classe. <%for (attribute) {%> <li><%name%> : <%type.name%></li> <%}%> Remarque : Le script ci-dessus appelle l'instruction <%type.name%> plutôt que l'instruction <%type%> car cette dernière provoque un affichage complexe. L'utilisation de l'attribut <%name%> permet de ne générer que le nom du type. Un test sur le nombre d'attributs est effectué afin d'améliorer la qualité du rendu. La structure conditionnelle «if» du langage Acceleo est alors nécessaire. La syntaxe de cette instruction est la suivante : <%if (condition) {%> expression <%} else {%> expression <%}%> Le bloc «else» est falcultatif. Il n'y a pas de moyen direct d'obtenir le nombre d'attributs dans une classe en UML2. Il faut avoir recourt à un service Acceleo. Le service «nsize» renvoie le nombre d'éléments contenus dans une liste. Le code pour l'affichage des attributs devient :

20 Page 20/75 <%if (attribute.nsize() == 0){%> <p>no attributes.</p> <%}else{%> <ul> <%for (attribute){%> <li><%name%> : <%type.name%></li> <%}%> </ul> <%}%> Le template est maintenant identique à celui de la figure Figure 4.20: Générateur XHTML final Avant d'effectuer la génération complète sur le modèle, un dernier test est nécessaire sur l'éditeur réflectif pour garantir que le résultat obtenu sera bien celui attendu. L'éditeur réflectif met bien à jour la liste des attributs de la classe, comme sur la figure 4.21, quand on effectue un clic droit «Acceleo > Reload Template» et qu'on sélectionne la classe «Utilisateur». Figure 4.21: Résultat final dans l'éditeur réflectif

21 Page 21/ Création de la chaîne d'exécution La génération globale peut maintenant être effectuée. Pour opérer une génération, il faut créer un fichier «Chain» définissant la liste des actions à réaliser. Les actions qui peuvent être définies vont de la génération de fichiers à la suppression de répertoire... L'assistant «File > New > Chain» (cf figure 4.22) permet de créer rapidement un fichier «Chain» dans un projet cible en donnant quelques informations sur les ressources mises en jeu. Figure 4.22: Création d'un nouveau fichier «Chain» L'assistant se décompose en quatre étapes : La première étape consiste à renseigner l'uri du méta-modèle du projet. Il s'agit de la même valeur que pour le générateur (cf figure 4.23). Dans la deuxième étape, le modèle d'entrée est demandé : «model/weblog_fr.uml» dans cet exemple. La troisième étape demande le script à exécuter, ici le template «xhtml.mt». Enfin dans la dernière page il faut spécifier le répertoire cible de la génération ainsi que le nom du fichier «Chain». Pour cela, il faut sélectionner le répertoire «WebContent» dans le champ «Container» (à l'aide du bouton «Browse» par exemple) et donner le nom «xhtml.chain» au fichier, comme sur la figure Cliquer sur «Finish» pour créer le fichier.

22 Page 22/75 Figure 4.23: Étape 1 et 4 de l'assistant de création de fichier «Chain» Le fichier «Chain» est créé dans le répertoire cible défini dans la quatrième étape de l'assistant («/fr.obeo.sample.demo.weblog.xhtml/webcontent»). Pour plus de clarté, il est préférable de le déplacer à la racine du projet (cf figure 4.24). Cette nouvelle chaîne de lancement contient les informations données à l'assistant. Elle peut être ouverte à l'aide d'un double clic dans l'explorateur de package. Elle est constituée de deux parties : un dépôt («Repository») référençant tous les artefacts liés à la génération : fichier du générateur, répertoire cible... un groupe d'actions («Action set») qui décrit notamment l'action de génération XHTML. Figure 4.24: Le projet cible de génération correctement structuré Ce premier scénario est simple. C'est pourquoi les informations données lors de la création sont suffisantes pour avoir un fichier parfaitement configuré pour le résultat attendu. Il peut maintenant être lancé pour générer tous les fichiers de description de classe au format XHTML.

23 Page 23/75 Le lancement de la génération s'effectue par un clic droit sur le fichier «xhtml.chain» et la sélection de l'action «Launch». Une barre de progression apparaît indiquant l'état d'avancement de l'opération. Une fois la barre disparue, le répertoire «WebContent» est précédé par un «+» pour indiquer qu'il contient des fichiers. Sept fichiers «.html» sont déployés, un par classe du modèle «WebLog_fr.uml» (cf figure 4.25). Il est possible de les ouvrir à l'aide du navigateur web du système (clic droit sur un fichier «.html» puis «Open with > System editor»). Figure 4.25: Résultat de la génération

24 Page 24/ Scénario 2 : générateur de classe de base Java Dans ce deuxième scénario, l'objectif est de créer un module capable de prendre un modèle UML2 en entrée et de créer un ensemble de fichiers Java. Un prototype sera mis au point, comme pour le premier scénario, puis un générateur sera réalisé à partir du prototype Création du prototype Le premier objectif est de créer des fichiers Java définissant les classes du modèle avec les accesseurs et les commentaires des attributs. La première étape consiste en la mise au point d'un fichier java respectant les objectifs souhaités. Remarque : Les projets précédents n'auront aucune incidence sur ce nouveau scénario, il est possible de les garder ouverts mais aussi de les fermer voir de les supprimer. Ils n'apparaîtront plus dans la suite de ce tutoriel Structure du projet prototype Dans un premier temps, il faut créer un projet Java de manière analogue au premier tutoriel : exécuter le menu «File > New > Project...». Dans la première étape de l'assistant de création de projet, il faut sélectionner l'item «Java Project» puis cliquer sur «Next». Dans la seconde étape, il faut renseigner le nom du projet : «fr.obeo.sample.demo.weblog.java» dans ce tutoriel. Attention! Si vous avez gardé les projets précédents, les noms des projets devront être différents des premiers. Lorsqu'une fenêtre Eclipse s'affiche pour proposer un changement de perspective, répondre «No» afin de rester sur la perspective Acceleo. Une fois le projet créé, l'ajout d'un répertoire source permet une meilleure structuration. L'ajout du répertoire s'effectue à l'aide du menu «File > New > Other» : sélectionner «Java > Source Folder», cliquer sur «Next», et donner le nom «src» au répertoire. Après le clic sur «Finish», l'explorateur de package d'eclipse contiendra un nouveau projet dont la structure est similaire à la figure 5.1. Figure 5.1: Le nouveau projet prototype

25 Page 25/ Classe Java prototype La structure est posée, il faut maintenant mettre au point le fichier java prototype : aller à nouveau dans le menu «File > New > Other», sélectionner «Java > Class», cliquer sur «Next», remplir les champs de l'assistant de la manière suivante : Package : fr.obeo.sample.demo.weblog Name : Prototype Cocher l'option «Generate comments» L'assistant doit être similaire à la figure 5.2. Le clic sur «Finish» finalise la création. Figure 5.2: Création de la classe Java prototype

26 Page 26/75 Le code suivant doit maintenant être inclus dans la nouvelle classe : private int attr1; private String attr2; /** Returns the attr1. */ public int getattr1() { return attr1; } /** * Set a value to attr1 attr1 The attr1 to set. */ public void setattr1(int attr1) { this.attr1 = attr1; } /** Returns the attr2. */ public String getattr2() { return attr2; } /** * Set a value to attr2 attr2 The attr2 to set. */ public void setattr2(string attr2) { this.attr2 = attr2; } Ce code définit deux attributs «attr1» et «attr2», les accesseurs associés et les commentaires de chaque accesseur. Cet exemple est assez simple mais le code pourrait respecter des standards de qualité beaucoup plus poussée sans augmenter la complexité du générateur qui en résultera. Le fichier doit ressembler à celui de la figure 5.3. Il est maintenant possible de produire le générateur à partir du prototype de cette classe. Figure 5.3: Prototype de classe Java

27 Page 27/ Création du générateur de base Structure du projet générateur De la même façon que dans le premier scénario, il faut créer un projet de génération nommé «fr.obeo.pim.uml2.gen.java». Afin d'améliorer la structuration du projet, il est conseillé de créer un package «fr.obeo.pim.uml2.gen.java» dans le répertoire «src» : après un clic droit sur le répertoire «src», sélectionner «New > Package» et renseigner le nom du nouveau package (cf figure 5.4). Puis, il faut créer un générateur vide dans ce package de la même façon que pour le premier scénario : URI UML2 et type racine «uml2.class». Le nom du nouveau template est «javaclass.mt». Le résultat doit être similaire à la figure 4.11 à l'exception du nom du template qui est «javaclass». Figure 5.4: Création d'un nouveau package

28 Page 28/ Du prototype au générateur Le code du prototype Java est situé en dessous de la balise «script» (cf figure 5.5). Modifier la valeur de l'attribut «file» de cette balise en «<%name%>.java» permet de changer le motif du fichier cible. La situation est identique à celle du prototype précédent avant l'ajout d'instructions dynamiques : le générateur est apte à produire des classes java depuis un modèle UML2 mais aucune valeur est transcrite dynamiquement. Par conséquent, les fichiers générés seraient identiques pour toutes les classes si le générateur était exécuté à ce moment. Il faut donc transformer le code du prototype de manière à obtenir un générateur correct. Figure 5.5: Générateur obtenu depuis le prototype Adaptation du prototype La classe Java générée doit avoir le nom de la classe du modèle. Pour cela, il suffit de remplacer le nom «Prototype» après le mot-clé «class» par l'instruction «<%name%>». Le nom sera maintenant transcrit dynamiquement. Le deuxième aspect à traiter dynamiquement est la déclaration des attributs. Il est nécessaire qu'elle soit réalisée en fonction des attributs définis dans le modèle. Il faut recourir à nouveau à l'instruction «for» en itérant sur les attributs pour ajouter leur déclaration. Le code est très similaire à celui produit dans le tutoriel précédent : <%for (attribute) {%> private <%type.name%> <%name%>; <%}%> Étant donné qu'en Java la déclaration des attributs est de la forme private type nom, les instructions < %type.name%> et <%name%> ont été permutées, le mot-clé «private» a été ajouté en début de ligne, et un point virgule à la fin. Après chaque modification de ce genre, une vérification de la validité du template dans l'éditeur réflectif est fortement conseillée, afin de vérifier la validité du template. Il faut à nouveau importer le modèle «WebBlog_fr.uml» dans le répertoire «model» du projet cible de génération «fr.obeo.sample.demo.weblog.java». Il est disponible sur le site Acceleo dans la section «Export XMI» de la rubrique «Documentation > Prise en main» : Le générateur «javaclass.mt» du package «fr.obeo.pim.uml2.gen.java» peut être sélectionné dans

29 Page 29/75 l'éditeur réflectif grâce au menu «Acceleo > Select Template». La pré-visualisation du code source de la classe «ArticleDeBlog» est disponible avec l'onglet «Source» de l'éditeur. La figure 5.6 montre ainsi que les attributs sont effectivement déclarés en se basant sur le modèle de WebLog. Figure 5.6: Les attributs de la classe sont déclarés selon le modèle Les accesseurs restent pour le moment incorrects car ils sont encore déclarés statiquement dans le générateur. Il faut effectuer une deuxième itération sur les attributs afin de définir le contenu des méthodes de récupération et d'affectation de chaque attribut. Cette partie de template est évidemment basée sur une boucle «for». Le code suivant pour l'attribut «attr1» peut servir de base : /** Returns the attr1. */ public int getattr1() { return attr1; } /** * Set a value to attr1 attr1 The attr1 to set. */ public void setattr1(int attr1) { this.attr1 = attr1; }

30 Page 30/75 Pour écrire le template, il faut remplacer toutes les occurrences de «attr1» par l'instruction <%name%> et toutes les référence au type int (qui était le type de l'attribut «attr1») par l'instruction <%type.name%> : <%for (attribute) {%> /** Returns the <%name%>. */ public <%type.name%> get<%name%>() { return <%name%>; } /** * Set a value to <%name%> <%name%> The <%name%> to set. */ public void set<%name%>(<%type.name%> <%name%>) { this.<%name%> = <%name%>; } <%}%> Finalement le code du générateur doit être similaire à celui de la figure 5.7. Figure 5.7: Générateur complet de classes java Le rechargement du générateur dans l'éditeur réflectif, avec le menu «Acceleo > Reload Template», confirme bien le fait que les accesseurs sont désormais générés en utilisant les informations du modèle. Cependant, une lecture attentive révèle que le nom des méthodes n'est pas bien formaté. En effet, les

31 Page 31/75 accesseurs du prototype avaient une majuscule après le mot «get» ou «set» ce qui n'est pas le cas dans l'éditeur réflectif à ce stade (cf figure 5.8). Figure 5.8: Erreur de formatage dans le nom des méthodes Correction de formatage Création puis utilisation de services Il y a deux cas de figure, le nom de l'attribut doit être transcrit tel quel ou bien avec la première lettre en majuscule. Il n'y a pas moyen d'obtenir simplement le nom d'un attribut de classe avec une majuscule à la première lettre. Il faut donc passer par un autre système afin de pouvoir agir sur les informations du modèle traité. Dans le premier exemple, le service «nsize» d'acceleo a été appelé afin de connaître le nombre d'éléments dans une liste (en l'occurrence le nombre d'attributs dans une classe). Il existe déjà un service dans Acceleo permettant de mettre une majuscule au nom d'un attribut, mais nous allons en réaliser un second pour l'exercice. La création d'un nouveau service se fait par le biais de la mise au point d'une classe Java. Afin de mieux structurer le projet, créer un nouveau package «fr.obeo.pim.uml2.gen.java.services» dans le projet : effectuer un clic droit sur le package «fr.obeo.pim.uml2.java» puis sélectionner «New > Package». Dans le champ «Name» entrer «fr.obeo.pim.uml2.gen.java.services» et enfin valider l'opération en cliquant sur «Finish». Un nouveau package apparaît en dessous du premier (cf figure 5.9). Figure 5.9: Un nouveau package pour rassembler les services utilisateur Une nouvelle classe Java doit être créée en effectuant un clic droit sur le nouveau package et en sélectionnant «New > Class». Dans le champ «Name» du nouvel assistant, entrer «StringFormat» puis cliquer sur «Finish» pour provoquer la création d'une classe portant le nom «StringFormat». Eclipse ajoute alors une classe java «StringFormat» dans le package nouvellement créé. Celle-ci, ou plus

32 Page 32/75 précisément ses méthodes, représentent de nouveaux services qui pourront potentiellement être appelés dans les templates Acceleo. Pour ce scénario, un service mettant la première lettre du nom d'un attribut en majuscule est nécessaire, il faut donc ajouter une méthode réalisant ce traitement. Dans le corps de la classe, la méthode suivante doit être ajoutée: public String firstupper(string s) throws ENodeCastException { if (s.length() > 0) s = Character.toUpperCase(s.charAt(0)) + s.substring(1); return s; } Le type de l'exception «ENodeCastException» n'est pas encore reconnu, il faut l'importer. Pour cela, il suffit de sélectionner «Organize import» dans le menu «Source» (cf figure 5.10). Une ligne d'import apparaît au dessus de la déclaration de la classe : import fr.obeo.acceleo.gen.template.eval.enodecastexception; Plus aucune erreur n'est notifiée par Eclipse, le service «firstupper» est désormais utilisable dans les templates Acceleo (cf figure 5.11). Figure 5.10: Organisation des imports par Eclipse Le service «firstupper» met le premier caractère d'une chaîne de caractères en majuscule. Il faut maintenant l'appeler dans le script «javaclass.mt» afin d'avoir une majuscule dans le nom des attributs pour générer les accesseurs. Figure 5.11: Le service «firstupper» utilisable dans Acceleo Dans un premier temps, il faut importer la classe Java créée précédemment pour accéder au service. L'import se fait par l'utilisation de la commande «import» dans l'en-tête du template. Il faut spécifier dans la commande le nom de la classe mais aussi le package dans lequel elle se trouve. Dans le cas présent, voici la ligne d'import : import fr.obeo.pim.uml2.gen.java.services.stringformat

33 Page 33/75 Figure 5.12: L'en-tête du template avec le service importé Une fois le service importé, il devient accessible dans le template, et il apparaît dans le système de complétion (cf figure 5.12 et 5.13). Figure 5.13: Le service «firstupper» apparaît désormais dans la complétion Acceleo Le premier paramètre défini dans la méthode «firstupper», et dans un service Java en général, correspond au receveur, c'est à dire le type d'objet sur lequel il s'applique. Le premier paramètre de la méthode «firstupper» est une chaîne, le service s'appliquera donc sur une chaîne. Dans la figure 5.13 le service «firstupper» peut s'appliquer sur le champ «name» d'un attribut car il s'agit d'une chaîne de caractères. Il ne reste plus qu'à appeler «firstupper» aux bons endroits dans le template et celui-ci renverra des sources Java correctement formatées. L'appel de ce service doit se faire lors de la génération du nom des accesseurs, il faut par conséquent remplacer la référence à <%name%> par <%name.firstupper()%> aux endroits ou ces noms sont définis. Le résultat doit être conforme à celui de la figure Figure 5.14: Template appelant le service «firstupper()» Les fichiers résultant doivent maintenant être correctement formatés. L'éditeur réflectif permet à nouveau de valider les modifications : après un clic droit sur le modèle «WebLog_fr.uml» sélectionner «Acceleo > Reload Template». En cliquant sur la classe «ArticleDeBlog», l'éditeur montre que les accesseurs seront désormais générés avec une majuscule.

34 Page 34/ Sélection des fichiers à générer Les tests avec l'éditeur réflectif ont pour le moment été effectués sur les classes «métier» du modèle «WebLog_fr.uml» (dans le package «métier»). Pour les classes du package «cinematic», cette génération n'a pas de sens. Il faut donc préciser au générateur qu'il ne faut créer que les fichiers du package «métier». Le moyen le plus facile est d'utiliser deux spécificités d'acceleo : le fichier n'est pas généré si la valeur de l'attribut «file» d'une balise «script» est vide ou nul il est possible d'utiliser un sous script pour définir le nom du fichier cible dans l'attribut «file» d'une balise «script» Les classes du package «métier» sont des entités et ont un stéréotype «Entity». La sélection des fichiers va donc s'effectuer par le biais de ce stéréotype : seules les classes stéréotypées «Entity» provoqueront la génération de classes Java Stéréotypes dans le modèle La première étape consiste à déterminer comment créer ce filtre sur les stéréotypes. Dans l'exemple du modèle «Weblog_fr.uml», les stéréotypes sont représentés par des «Keywords» (cf figure 5.15). Il faut maintenant réaliser un service Java pour tester si une classe possède un stéréotype. Figure 5.15: La classe «Utilisateur» est stéréotypée «Entity»

35 Page 35/ Service «hasstereotype» Le service «hasstereotype» doit être placé dans une nouvelle classe : pour la créer, effectuer un clic droit sur le package «fr.obeo.pim.uml2.gen.java.services» puis sélectionner «New > Class» pour lancer l'assistant. Afin de nommer la classe «ClassesServices», remplir le champ «Name» en conséquence et cliquer sur «Finish» pour valider le traitement. Dans cette nouvelle classe, rajouter une nouvelle méthode «hasstereotype» avec la signature suivante : public boolean hasstereotype(element elt, String stereotype) { } Pour importer l'interface «org.eclipse.uml2.uml.element», ajouter la dépendance vers «org.eclipse.uml2.uml» dans le fichier MANIFEST.MF du projet et utiliser le menu «Source > Organize Imports». Le service «hasstereotype» porte sur des «Element» UML2 et prend en paramètre une chaîne de caractères. La chaîne «stereotype» représente le stéréotype recherché. Dans le corps de la méthode, ajouter le code suivant : if (elt.haskeyword(stereotype)) { return true; } return false; si l'élément a un «keyword» correspondant à la chaîne passée en paramètre du service, celui-ci renvoie «true» sinon, il renvoie «false» Filtre des classes à l'aide du service «hasstereotype» La commande suivante permet d'importer la nouvelle classe de services dans le générateur «javaclass.mt» : import fr.obeo.pim.uml2.gen.java.services.classesservices Le script suivant permet de préciser le nom des fichiers à générer pour les classes stéréotypées «Entity» : <%script type="uml2.class" name="filename"%> <%if (hasstereotype("entity")){%> <%name%>.java <%}%> Ce script s'applique à des objets de type «Class» et a pour nom «filename». Il définit que si la classe cible a le stéréotype «Entity», il génère la chaîne composée du nom de la classe suivi de «.java». Appliqué au modèle «WebLog_fr.uml» cela donnera : «ArticleDeBlog.java» et «Utilisateur.java» pour les deux classes contenues dans les packages «métier.blog» ; «null» pour les autre classe de modèle (celles-ci se trouvant dans des packages nommés «utilisateur» ou «principal»). Remplacer l'instruction «<%name%>.java» dans l'attribut «file» de la balise racine par un appel au script nouvellement défini : <%script type="uml2.class" name="javaclass" file="<%filename%>"%>

36 Page 36/75 Le générateur est maintenant équivalent à celui de la figure Les classes du package «cinematic» ne sont plus affectées par la génération quand le template est rechargé dans l'éditeur réflectif : les décorateurs de ces classes ont disparu (cf figure 5.17). Figure 5.16: Sélection des classes en fonction du stéréotype Figure 5.17: Seules les classes du package «métier» ont un décorateur

37 Page 37/ Création du fichier d'exécution L'entrée «New > Chain» du menu contextuel du projet «fr.obeo.sample.demo.weblog.java» permet de lancer l'assistant de création de chaîne d'exécution : Sélectionner à nouveau l'uri de UML2 ; Sélectionner le modèle «WebLog_fr.uml» du projet «fr.obeo.sample.demo.weblog.java» ; Cocher le générateur «javaclass.mt» dans le package «fr.obeo.pim.uml2.gen.java» ; Nommer cette chaîne «java.chain». Un nouveau fichier «chain» est créé avec des informations similaires à celui créé dans la section précédente. Seul le répertoire cible de génération n'est pas correct, en effet il cible la racine du projet mais les fichiers doivent être générés dans le répertoire «fr.obeo.sample.demo.weblog» pour être conformes à leur package. Pour corriger cela, effectuer un double clic sur la ligne désignant la cible de génération (la deuxième du «Repository») : une nouvelle fenêtre s'ouvre pour le choix du répertoire cible. Modifier ce répertoire en sélectionnant «src/fr/obeo/sample/demo/weblog» et valider ce changement en cliquant sur «Ok» (cf figure 5.18). La chaîne d'exécution est désormais correctement configurée il ne reste plus qu'à la lancer : effectuer un clic droit sur le fichier «java.chain» et sélectionner «Launch». Deux fichiers «ArticleDeBlog.java» et «Utilisateur.java» sont alors créés. Les deux sont syntaxiquement corrects cependant le fichier «ArticleDeBlog.java» possède des erreurs de compilation. La classe fait référence à l'objet «Date» qui n'est pas un type de base du langage Java. Le problème peut-être résolu en ouvrant le fichier et en exécutant le menu «Source > Organize Imports» puis en sélectionnant le type «java.util.date». Ce tutoriel montrera, dans les parties suivantes, comment gérer ce genre de problème. Figure 5.18: Modification du répertoire cible de génération

38 Page 38/ Amélioration du générateur La première partie de ce scénario a permis la mise au point d'un générateur très basique de classes java depuis un modèle UML2. Grâce à celui-ci, il est tout à fait possible de diminuer le taux de travail automatique en évitant la frappe de la déclaration des attributs ainsi que de leurs accesseurs pour toutes les classes d'un projet. Les générations des signatures des méthodes et des constructeurs paramétrés peuvent aussi être envisagées Gestion des opérations Dans un modèle UML2, il est possible de spécifier les opérations d'une classe. Acceleo permet de générer automatiquement leur signature. Les opérations d'une classe sont accessibles par l'élément «ownedoperation». Tout comme pour les attributs, la définition des méthodes des classes va passer par une boucle «for» sur «ownedoperation». <%for (ownedoperation) {%> /** * <%name%> method * */ public <%type.name%> <%name%>() { } <%}%> Ce premier jeu d'instructions permet de générer chaque opération déclarée dans le modèle avec un commentaire, son nom, son type de retour... La classe «Utilisateur» du modèle «WebLog_fr.uml» possède une opération «chercheparloginetmotdepasse». Il est donc possible de voir le résultat de cette première modification en rechargeant le générateur dans l'éditeur réflectif et en consultant les sources de cette classe (cf figure 5.19). Figure 5.19: Modification dans le générateur et résultat dans l'éditeur

39 Page 39/75 Ce résultat peut encore être amélioré en gérant les paramètres des méthodes. Il faut générer leur nom et leur type, et les séparer par des virgules. returntype name(typeparam1 nomparam1, typeparam2 nomparam2,...) { } Acceleo possède un service «sep» prenant une chaîne de caractères en paramètre et séparant chaque élément d'une liste par cette chaîne. Le script suivant permet de générer la déclaration d'un paramètre : <%script type="uml2.parameter" name="parameterdeclaration"%> <%type.name%> <%name%> Ce script renvoie le type et le nom du paramètre sur lequel il s'applique. En l'appelant sur la liste des paramètres d'une opération, Acceleo retournera une liste de la forme : typeparam1 nomparam1 typeparam2 nomparam2... typeparamn nomparamn La combinaison de ce script et du service «sep» d'acceleo donnera le résultat escompté. Après avoir ajouter le script «parameterdeclaration» dans le template «javaclass.mt», insérer l'instruction : <%parameter.parameterdeclaration.sep(",")%> dans le script «javaclass.mt» entre les parenthèses dans la partie générant les méthodes de la classe. Le résultat doit être semblable à la figure En l'état actuel, le générateur «javaclass» est apte à générer des classes java depuis un modèle UML2 avec les attributs des classes, les accesseurs associés ainsi que les opérations définies par le concepteur. Le résultat peut évidemment être consulté dans l'éditeur réflectif en rechargeant le générateur : la classe «Utilisateur» possède bien une méthode «chercheparloginetmotdepasse» avec les trois paramètres user, login et motdepasse. Figure 5.20: Gestion des paramètres des méthodes Remarque : Il est possible de traduire chaque boucle «for» par un sous script du template comme sur la

40 Page 40/75 figure 5.21, cependant plus un template est découpé moins il est lisible. Il est donc conseillé d'utiliser un «for» dès que possible. Figure 5.21: Les méthodes générées à l'aide d'un script Génération incrémentale Usage des balises de code utilisateur Pour le moment, toutes les modifications apportées à un fichier généré sont écrasées à la génération suivante. Pour résoudre ce problème, Acceleo possède un mécanisme de balises permettant de définir des zones destinées à accueillir du code utilisateur qui ne sera pas écrasé à la génération suivante. Ils faut ajouter ces balises aux bons endroits dans le template afin de pouvoir insérer du code utilisateur résolvant les problèmes actuels de la génération. Étant donné que dans les fichiers Java la définition des imports se fait avant la déclaration de la classe, il faut ajouter le code suivant entre la définition du package et la déclaration de la classe (cf figure 5.22) : //<%startusercode%> for imports //<%endusercode%> for imports Remarques : L'utilisation de la complétion est indispensable pour une bonne productivité dans la création des générateurs, dans le cas du code utilisateur, les trois premières lettres «sta» rendent la complétion des balises accessibles et permettent d'éviter de la frappe inutile au clavier le texte sur la même ligne que la balise <%startusercode%> sera retranscrit dans le fichier généré et sert d'identifiant pour la zone de code utilisateur, cet identifiant doit être unique pour l'ensemble du fichier. Figure 5.22: Balises de code utilisateurs pour les imports

41 Page 41/75 Une fois le générateur rechargé, l'éditeur réflectif montre les deux commentaires qui délimitent la zone d'imports où les développeurs peuvent ajouter du code manuel (cf figure 5.23). Figure 5.23: Balises de code utilisateurs dans le code généré Lors de la dernière génération, une nouvelle erreur s'est introduite dans le résultat : les méthodes déclarant un type de retour doivent retourner un résultat de ce type sinon le compilateur Java rejette le code. La méthode «chercheparloginetmotdepasse» retourne un résultat de type «Utilisateur», le fichier généré a donc une erreur de compilation à ce niveau. Une solution simple pour ce problème est de généré par défaut une instruction «return null;» afin d'éliminer l'erreur de compilation. Pour appliquer cette solution, il est possible d'ajouter simplement «return null;» dans la partie générant les méthodes cependant, lorsque la méthode aura son contenu réel, une nouvelle génération le supprimera. Afin de se prémunir de ce désagrément, il est également possible d'ajouter cette instruction entre deux balises de code utilisateur. Ainsi, à la première génération le code sera généré avec une instruction simple évitant l'erreur de compilation et par la suite, lorsqu'un développeur aura mis le contenu réel de la méthode, il sera conservé. Dans la partie du template générant les méthodes de la classe, il faut donc ajouter le code suivant : //<%startusercode%> for <%name%> method body return null; //<%endusercode%> for <%name%> method body Le résultat doit être similaire à la figure 5.24.

42 Page 42/75 Figure 5.24: Code utilisateur pour le corps des méthodes Après un premier lancement de la chaîne d'exécution, seul le fichier «ArticleDeBlog.java» aura une erreur de compilation (à cause des imports). L'ajout du code suivant réglera ce problème de manière définitive : import java.util.date; Gestion de l'héritage Un problème risque de se poser dans le cas où la classe hérite d'une autre classe. Il serait possible d'ajouter des balises de code utilisateur afin de permettre la gestion des généralisations mais cela rendrait le code généré illisible. La deuxième solution consiste à gérer l'héritage depuis le modèle UML2 directement. Dans le code du template Acceleo, entre la référence au nom et l'accolade ouvrante de la classe, il faut insérer le code suivant : <%if (superclass!= null){%>extends <%superclass.nget(0).name%> <%}%> le template doit être similaire au final à la figure Cette condition impose que si le lien «superclass» est défini dans le modèle pour la classe courante, alors le mot clé «extends» est généré suivi du nom de la première classe référencée par «superclass». La façon de gérer l'héritage du modèle UML2 vers le code source Java est un choix. Étant donné que UML2 autorise l'héritage multiple contrairement au Java, le choix a été fait ici de faire étendre la classe générée de la première classe référencée comme super classe (ceci à l'aide de l'instruction «nget(0)» qui renvoie le premier élément de la liste). Des méthodes pour gérer l'héritage plus efficacement peuvent être mise en oeuvre mais celles-ci ne seront pas traitées dans ce tutoriel.

43 Page 43/75 Figure 5.25: Une façon de générer l'héritage en Java Le modèle «WebLog_fr.uml» ne possède pas d'héritage de classe. Il est conseillé de créer un modèle UML2 afin de tester cette partie du tutoriel Constructeur paramétré Régulièrement un constructeur paramétré est créé pour les classes Java. Celui-ci prend en paramètre une liste équivalente à celle des attributs de la classe et effectue une affectation variable à variable. La génération de ce genre de constructeur est aisée avec Acceleo. /** * parameterized constructor * */ public <%name%>(<%attribute.parameterdeclaration.sep(",")%>) { <%for (attribute){%> this.<%name%> = <%name%>; <%}%> } Ce code définit le nouveau constructeur paramétré de la classe. Il a pour nom celui de la classe et pour paramètres les attributs de la classe. La portion «attribute.parameterdeclaration» génère une erreur, en effet, le script «parameterdeclaration» définit précédemment s'applique sur des objets de type «uml2.parameter» or les attributs de classes ne sont pas de ce type. Il faut donc définir ce script pour les attributs. Ceux-ci étant de type «Property», il faut ajouter à la fin du template le code suivant : <%script type="uml2.property" name="parameterdeclaration"%> <%type.name%> <%name%> Une fois le template corrigé et sauvegardé, l'erreur disparaît et le générateur est à nouveau valide. Le corps du constructeur est basé sur une boucle sur les attributs : à chaque attribut est généré une ligne de la forme : this.nomattr = nomattr; Un rechargement du générateur dans l'éditeur réflectif confirme la création des constructeurs paramétrés. La chaîne peut être à nouveau lancée.

44 Page 44/ Scénario 3 : personnalisation du module d'exemple JSP/JDBC Ce nouveau tutoriel traite de la prise en main et de la personnalisation de modules existants. Dans un premier temps, l'objectif est de récupérer le module JSP/JDBC d'exemple sur le site web d'acceleo, de l'appliquer sur le modèle de WebLog et de tester l'application. La deuxième partie tend à personnaliser le module en modifiant légèrement la cible de génération Installation et test du module JSP/JDBC Récupération et installation du module sur le site Acceleo.org Le module d'exemple peut être téléchargé sur le site d'acceleo dans la partie «Téléchargement > Modules d'exemple» (cf figure 6.1). Figure 6.1: Téléchargement du module d'exemple Acceleo Une fois le module téléchargé, il faut l'installer : lancer le menu «File > Import...», sélectionner «Existing Projects into Workspace» et cliquer sur «Next» pour passer à la page suivante. Cocher «Select archive file» pour spécifier à l'assistant que le module se trouve dans un fichier archive et à l'aide du bouton «Browse...» sélectionner le fichier téléchargé depuis le site web d'acceleo «module-exemple zip» (cf figure 6.2). Il faut penser à sélectionner les trois projets «free.demo.weblog», «free.uml1_4.gen.java» et «free.uml2.java» avant de cliquer sur «Finish». Trois projets supplémentaires sont alors chargés dans le workspace Eclipse, un projet Java et deux projets de génération (ceux-ci étant différentiables par leurs décorateurs similaires à la figure 4.8).

45 Page 45/75 Le module est maintenant pleinement utilisable : les modèles, les bibliothèques utiles et les chaînes de génération sont dans le projet Java. Les générateurs sont placés dans les projets de génération en fonction de la version du méta-modèle UML sur lequel ils s'appliquent. Figure 6.2: Import du module d'exemple JSP/JDBC Il n'y a que quelques différences entre les deux projets de génération, seul le projet portant sur UML2 sera détaillé Analyse de l'existant du module Le module JSP/JDBC est constitué de six générateurs et de deux services, le tout orchestré par une chaîne d'exécution (en faisant abstraction de la chaîne «weblog.clean.chain» qui n'est utilisé que pour nettoyer le projet cible). Les services sont regroupés dans un package «org.acceleo.modules.uml2.services», et les générateurs se trouvent dans trois packages : «org.acceleo.modules.uml2.gen.java.dao» contient le générateur des classes d'accès aux données «org.acceleo.modules.uml2.gen.java.dto» contient le générateur des classes de transfert «org.acceleo.modules.uml2.gen.java.ui» contient les générateurs liés à l'interface web Ce module est destiné à être utilisé lors de la réalisation d'un site web depuis un modèle UML2. Le modèle UML2 définit les écrans et les entités (objets qui devront être sauvegardés en base de données) par des classes et les développeurs doivent implémenter les pages web et les objets Java en conséquence afin d'obtenir le résultat décrit par la conception. Le module JSP/JDBC s'inscrit dans cette logique en permettant la génération de la partie automatique du code pour laisser les développeurs se concentrer sur la partie métier de l'application. Les générateurs de la partie interface vont générer les pages JSP, la page de navigation, la partie générique des actions struts, et le fichier de configuration de la servlet «web.xml».

46 Page 46/75 Le générateur de classes de transfert va générer les classes DTO. Enfin le générateur des classes d'accès aux données générera la majorité du code des DAO Générateur de pages JSP Le générateur JSP n'utilise pas les balises habituelles «<%...%>» car elles pourraient se confondre avec celles du langage JSP. Acceleo autorise l'utilisation d'autres balises : «[%...%]». Le générateur utilise le même principe que celui du scénario 2 pour sélectionner les classes susceptibles d'être générées : les classes ayant le stéréotype «Screen». Un fichier portant le nom de la classes suivi de l'extension «.jsp» est généré pour chaque classe stéréotypée «Screen». Ceci est défini par le script «fullfilepath» : [%if (hasstereotype("screen")){%] /[%package.name%]/[%name%].jsp [%}%] Le corps de la JSP est défini dans le script principal. Le titre est basé sur le commentaire de la classe et l'action de la page sur le nom de la classe. Ensuite pour chaque attribut de la classe n'étant pas issu d'une association, une zone de texte est générée précédée par le nom de l'attribut. L'identifiant de la zone de texte est également basé sur le nom de l'attribut. Un bouton de validation est créé pour chaque opération d'une classe, et un lien direct est généré en bas de la page pour toutes les associations qu'une classe possède vers d'autres classes Générateur de la page de navigation Afin de pouvoir naviguer plus facilement dans le site, une page de navigation est créée par le générateur «navigation.mt». Celui-ci créé tout simplement une page «index.html» possédant un lien vers toutes les classes «Screen» du modèle Génération d'actions Pour chaque classe, une servlet d'action est générée afin de pouvoir gérer les actions requises par l'utilisateur. Les identifiants de page (de type «PAGE_SELF», «PAGE_CONNECTION»,...) sont définis dans la servlet, les méthodes «dopost» et «doget» sont redirigées sur la méthode «doaction». Le corps de la méthode est aussi généré depuis le modèle : pour chaque opération de la classe, la méthode «doaction» redirige la requête vers une opération du même nom. Une méthode d'initialisation est également générée. Elle contient le code à exécuter au lancement de la servlet. Enfin, pour chaque opération de la classe, une méthode est générée avec des balises utilisateurs pour définir le code manuel de la cinématique de l'interface. Les classes susceptibles d'être générées sont à nouveau filtrées par le script «fullfilepath».

47 Page 47/75 <%script type="class" name="fullfilepath"%> <%-- Only Classes with stereotype Screen--%> <%if (hasstereotype("screen")){%> /<%scenariopackage.topath()%>/<%name%>servlet.java <%}%>... <%script type="class" name="scenariopackage"%> <%-- ui struts package --%> org.acceleo.sample.ihm Configuration de l'application web fichier «web.xml» Les conteneurs d'application web ont besoin d'un fichier décrivant la configuration d'une servlet. Ce fichier est aussi généré automatiquement depuis le modèle grâce au module JSP/JDBC. Le générateur «web.mt» définit statiquement les informations de configuration de l'application, dynamiquement les informations des servlets, et le mapping entre les pages appelées et celles-ci. Une servlet est déclarée pour chaque opération de la classe Classes de transfert de données Le générateur «dto.mt» permet la génération des classes de transfert. Pour chaque classe du modèle UML2, une classe Java est générée. Si dans le modèle la classe hérite d'une autre classe, cet héritage sera retranscrit dans la classe Java (entre les deux classes DTO). Chaque attribut est retranscrit en attribut java ayant des accesseurs. Au final, ces classes sont générées dans un package (filtrage par le stéréotype «Entity» ou «Dto») dont le nom est paramétré par un autre script Classes d'accès aux données Les classes d'accès aux données (DAO) sont les classes qui vont chercher les objets stockées dans la base de données de l'application. Le générateur «jdbc.mt» permet la création automatique de ces classes. Le nom de la table stockant les objets instanciés est généré de la manière suivante : protected final static String TABLE_NAME = "T_<%name%>"; Voici aussi la manière de générer le nom de tous les attributs de la base de données : <%for (attribute){%> protected final static String <%name.touppercase()%> = "<%name%>"; <%}%> Les requêtes (ajout, suppression, mise à jour,..) et les opérations qui peuvent être réalisées en base sont générées pour chaque classe : createclasse : ajout d'une nouvelle instance en base updateclasse : mise à jour d'une instance deleteclasse : suppression d'une instance de la base findallclasses : renvoie de toutes les instances de la classe en base findclassebyid : récupération d'un élément par son identifiant Comme pour les autres classes java, seules les classes ayant le stéréotype «Entity» sont générées et elles sont placées dans un package dont le nom est paramétré par un autre script.

48 Page 48/ Résultat de la génération du module Il est maintenant possible d'utiliser la chaîne d'exécution fournie dans le projet «free.demo.weblog» : effectuer un clic droit sur le fichier «weblog.chain» et sélectionner l'action «Launch». La chaîne produit 16 fichiers (cf figure 6.3) : 2 DTO pour les entités ; les 2 DAO de ces mêmes classes ; les 5 JSP des écrans ; les 5 servlets qui leur sont associés ; la page d'accueil «index.html» ; la configuration de l'application «web.xml». Figure 6.3: Résultat de la chaîne «weblog.chain» Normalement le résultat de la chaîne d'exécution est immédiatement exploitable. Remarque : Il se peut qu'il manque une bibliothèque dans le chemin de construction, dans ce cas reportez vous à votre administrateur système afin de connaître la configuration que vous pouvez adopter pour exécuter des applications web. Si Eclipse ne présente aucun problème de résolution d'import, exécuter la servlet en effectuant un clic droit sur le fichier «index.html» puis en sélectionnant le menu «Run as... > Run on Server» (cf figure 6.4). Une fois les informations nécessaires au lancement de la servlet renseignées, le conteneur d'applications se lance, puis un navigateur s'ouvre en affichant la page d'accueil générée (cf figure 6.5). La navigation entre les différents écrans de l'application est possible car les liens et les pages JSP correspondantes sont tous générés et valides (cf figure 6.6). Seul l'intelligence des actions est à rajouter à la main pour chaque écran. Toutes les interactions avec la base de données sont générées et parfaitement utilisables.

49 Page 49/75 Figure 6.4: Exécution du projet sur un serveur Figure 6.5: Page d'accueil du site générée par le module JSP/JDBC Figure 6.6: Exemple de formulaire généré par le module JSP/JDBC L'utilisation de la chaîne «weblog.uml14.chain» ne sera pas plus détaillée dans ce tutoriel. Le résultat de son exécution est similaire à celui décrit ci-dessus à la seule différence que le modèle utilisé est de type UML 1.4 et non UML2.

50 Page 50/ Personnalisation du module Maintenant que le contenu et la cible de génération sont appréhendés, il est tout à fait possible de personnaliser le module afin de pouvoir l'adapter aux besoins d'une société ou d'un utilisateur en particulier. Cette partie donne quelques exemples de personnalisations qui peuvent être mises en oeuvre avec ce module Ajout d'un générateur SQL Nouveau fichier générateur Pour le moment, ce module d'exemple se contente de générer des fichiers Java, Web ou de configuration. Étant donné qu'il utilise le framework JDBC vers une base de données pour persister les objets de l'application, il serait intéressant de créer automatiquement les schémas de base SQL afin de n'avoir qu'à les appliquer dans la base cible et ainsi être sur de la bonne compatibilité entre la base de données et l'application. La première étape consiste à ajouter un générateur au module (NdR: La personnalisation du module se basera à nouveau sur le projet «free.uml2.gen.java»). Afin de garder une bonne structuration, ce générateur sera ajouté dans un package dédié à la base SQL. Il faut commencer par créer ce package. Après un clic droit sur le répertoire «src», sélectionner «New > Package» puis, dans la fenêtre de création de nouveau package, entrer le nom «org.acceleo.modules.uml2.gen.sql» et valider en cliquant sur «Finish». Le nouveau package apparaît dans le projet, il est désormais possible de créer un nouveau générateur. Pour lancer l'assistant de création du générateur, il faut effectuer un clic droit sur le package «org.acceleo.modules.uml2.gen.sql» puis un clic sur «New > Empty Generator» (cf figure 6.7), définir que ce générateur s'applique sur le méta-modèle UML2 en sélectionnant son URI, positionner le type racine du template sur «uml2.model» pour signifier que le fichier SQL sera généré pour tout le modèle, et nommer le générateur «sql-table.mt». Figure 6.7: Ajout d'un nouveau générateur au module dans un nouveau package Un nouveau générateur est créé en se basant sur l'objet de haut niveau d'un modèle UML2 : l'objet «Model». Il faut maintenant créer un script qui, pour chaque classe du modèle ayant le stéréotype «Entity» (i.e. en corrélation avec un objet DAO), génère le schéma d'une table de base de données SQL.

51 Page 51/ Générateur SQL Dans un premier temps, il faut changer le nom du fichier généré en «tables.sql» (attribut «file» de la balise racine) et insérer le code suivant afin de positionner la base de données : -- Database USE sample; Il faut maintenant générer un schéma pour chaque classe ayant le stéréotype «Entity». Dans les templates déjà existant,s le service «hasstereotype(«chaîne»)» est utilisé sur une classe pour savoir si elle possède le stéréotype «Chaîne». Ce service sera utile pour déterminer si une classe doit générer un schéma ou non. Le service «eallcontents» permet, dans un script, de récupérer tous les objets contenus dans un élément. Ainsi, dans le script en cours de définition, le service «eallcontents» renverra tous les objets du modèle traité. Quand une chaîne est passée en paramètre de ce service, seuls les objets dont le type correspond à la chaîne sont renvoyés. Par conséquent, l'instruction <%eallcontents(«class»)%> renverra toutes les classes du modèle traité. En se basant sur les services «hasstereotype» et «eallcontents», il est possible désormais de définir une boucle générant du texte pour toutes les classes du modèle possédant le stéréotype «Entity» : <%for (eallcontents("class")) {%> <%if (hasstereotype("entity")) {%> [Schéma table SQL] <%}%> <%}%> Il existe un autre service permettant de simplifier cette partie de code : le service «select». Il s'applique sur une liste d'éléments et prend en paramètre une chaîne de caractères définissant une expression booléenne. L'expression est évaluée pour chaque élément de la liste. Le résultat contient tous les éléments pour lesquels l'évaluation de l'expression renvoie «vraie». En appliquant le service «select» au résultat de «eallcontents» avec l'expression «hasstereotype» le résultat sera similaire au code précédent : <%for (eallcontents("class").select("hasstereotype('entity')")){%> [Schéma table SQL] <%}%> Remarque : Si l'expression booléenne nécessite l'utilisation de guillemets (comme dans le code précédent), il suffit de les remplacer par des apostrophes afin de corriger les erreurs de syntaxe. La table SQL créée pour une classe entité doit contenir une colonne par attribut de classe. La génération du schéma se fera donc par une boucle sur les attributs de la classe. Avant de la mettre en oeuvre, il reste un problème à gérer : les types SQL ne sont pas les mêmes que les types UML2. Il faut donc créer un script réalisant un mapping entre les types.

52 Page 52/75 Le type «Integer» correspond au type «NUMBER» en SQL, le type «Date» à «DATETIME» et le type «String» au type «VARCHAR» qui sera quantifié classiquement à 255 caractères. Le script correspondant est le suivant : <%script type="uml2.type" name="tosqltype"%> <%if (name == "String"){%> VARCHAR(255) <%}else if (name == "Date") {%> DATETIME <%}else if (name == "Integer") {%> NUMBER <%}else{%> CHAR(32) <%}%> Dans le cas où le type ne serait pas un de ceux décrit précédemment, le mapping renverra un type «CHAR(32)» équivalent au type des identifiants (il sera ainsi possible de réaliser des liaisons entre les tables pour les associations entre classes). En utilisant ce script pour la génération des schémas, cela donne : <%for (eallcontents("class").select("hasstereotype('entity')")){%> -- TABLE FOR <%name%> class CREATE TABLE T_<%name%> ( ID CHAR(32) NOT NULL, <%for (attribute){%> <%name%> <%type.tosqltype.trim()%> NOT NULL, <%}%> PRIMARY KEY (ID) ); <%}%> Pour chaque table, un attribut ID est généré pour pouvoir identifier chaque élément. Cet attribut est utilisé par le générateur DAO pour retrouver les objets depuis leurs identifiants. Une fois le code retranscrit, le générateur doit être similaire à la figure 6.8. Figure 6.8: Générateur de table SQL

53 Page 53/75 Une vérification du template est nécessaire avec l'éditeur réflectif avant son intégration dans la chaîne de génération : ouvrir le modèle «free.demo.weblog/model/weblog_fr.uml» en effectuant un double clic puis sélectionner le menu contextuel «Acceleo > Select Template». Il faut cocher le fichier «sql-table.mt» dans la fenêtre de sélection du générateur, et cliquer sur «Ok» pour valider l'assistant (cf figure 6.9). Figure 6.9: Sélection du générateur SQL Un décorateur apparaît sur le modèle. En le sélectionnant et en activant l'onglet «Source», le résultat de la génération est affiché. Le fichier SQL montre deux tables correspondants aux entités du modèle de blog (cf figure 6.10). Figure 6.10: Le schema SQL du modèle de blog

54 Page 54/75 Le résultat étant satisfaisant, il est désormais possible d'intégrer ce générateur dans la chaîne d'exécution «weblog.chain» Modification de la chaîne d'exécution Ouvrir la chaîne «weblog.chain» par un double-clic sur le fichier. Le fichier chaîne, contrairement à ceux élaborés pour le moment, possède plusieurs groupes d'actions. Il est en effet possible de définir plusieurs groupes d'actions dans un même fichier et de définir plusieurs actions à exécuter dans un groupe d'actions. La chaîne du module d'exemple possède un groupe d'actions «clean» qui efface les fichiers de logs et plusieurs groupes d'actions appelant les différents générateurs du module. Afin d'appeler le générateur SQL et de garder une bonne structuration du fichier «Chain», un nouveau groupe «SQL» doit être créé : effectuer un clic droit sur l'objet «Chain» puis sélectionner «New > Action Set» (cf figure 6.11). Figure 6.11: Nouveau groupe d'actions Un nouveau groupe d'actions apparaît à la suite de ceux déjà existant. Effectuer un clic droit sur ce nouveau groupe et sélectionner «Show Properties View». Une nouvelle vue s'ouvre avec une ligne «Documentation». En donnant une valeur à cette clé, le nom du groupe d'actions sera modifié. Une action de chaîne ne peut faire référence qu'à des fichiers et des répertoires référencés dans le dépôt («Repository»). Avant de créer l'action appelant le générateur SQL, il faut donc ajouter les références qui vont être nécessaires dans le dépôt de la chaîne. La création de l'action nécessite la référence à un générateur, un répertoire cible, un fichier de log, un métamodèle et un modèle. En ce qui concerne ces trois derniers éléments, l'action se basera sur ceux déjà existants. Il faut ajouter une référence vers le générateur SQL et une autre vers un nouveau répertoire cible. Remarque : Il est tout à fait possible de cibler un répertoire déjà utilisé pour le générateur SQL. Cependant, dans ce tutoriel, les schémas de tables seront exportés vers un répertoire «resources», toujours dans un esprit de structuration. Pour ajouter une référence vers le générateur «sql-table.mt», effectuer un clic droit sur l'objet «Repository» de la chaîne puis sélectionner «New > Child > Generator» (cf figure 6.12). Ensuite une référence vers le chemin du générateur de table SQL doit être définie pour l'action de génération : effectuer un double clic sur le nouvel objet «Generator» qui apparaît en bas du dépôt puis sélectionner le fichier «sql-table.mt».

55 Page 55/75 Figure 6.12: Nouveau générateur dans le dépôt Cocher le fichier «/free.uml2.gen.java/src/org/acceleo/modules/uml2/gen/sql/sql-table.mt» dans la fenêtre de sélection du générateur et cliquer sur «Ok» pour référencer le générateur SQL (cf figure 6.13). Figure 6.13: Le dépôt de la chaîne référencie bien le générateur «sqltable.mt» Il ne reste plus qu'à ajouter une référence vers le répertoire cible pour pouvoir définir la nouvelle action de génération. L'ajout d'un nouveau répertoire cible passe par la sélection du menu «New Child > Folder» sur l'objet «Repository». Un nouvel objet «Folder» est ajouté à la fin du dépôt de la chaîne. Il faut maintenant effectuer une référence vers le répertoire «resources», pour cela double cliquer sur l'objet «Folder» nouvellement créé puis, dans la fenêtre qui s'ouvre, sélectionner le projet «free.demo.weblog». Le répertoire «resources» n'existant pas encore dans le workspace Eclipse, cliquer sur le bouton «Create Folder» afin de lancer la fenêtre de création de répertoire. Dans le prompt interrogeant sur le nom du répertoire à créer, entrer «resources». Il ne reste plus qu'à cliquer sur «Ok» pour valider la nouvelle configuration (cf figure 6.14). Figure 6.14: Création d'un nouveau répertoire «resources»

56 Page 56/75 Toutes les références nécessaires sont présentes dans le dépôt, il est maintenant possible d'ajouter l'action de génération. Après la sauvegarde du fichier «weblog.chain» («File > Save»), il faut ajouter une nouvelle action de génération au fichier, pour cela effectuer un clic droit sur le groupe d'actions SQL puis sélectionner «New Child > Generate» (cf figure 6.15). Figure 6.15: Nouvelle action de génération Un nouvel objet «Generate» est ajouté au groupe d'actions «SQL». Afficher la vue de propriétés à l'aide du menu «Show Properties View» de cet objet. La propriété «Documentation» permet de donner un nom à l'action de génération, dans le cadre de ce tutorial la valeur «Tables» lui sera affectée. En cliquant sur le champ de la propriété «Folder», un bouton de défilement apparaît. Il faut sélectionner le répertoire cible de la génération SQL : «/free.demo.weblog/resources». Le même mécanisme permet de choisir : le générateur «/free.uml2.gen.java/src/org/acceleo/modules/uml2/gen/sql/sql-table.mt» pour la clé «Generator» le fichier de log «/free.demo.weblog/genlog.log» pour la clé «Log» le métamodèle « pour la clé «Metamodel» le modèle «/free.demo.weblog/model/weblog_fr.uml» pour la clé «Model» Figure 6.16: L'action de génération complètement configurée

57 Page 57/75 La vue de propriétés doit maintenant avoir des valeurs identiques à celles de la figure Il est nécessaire de sauvegarder le fichier pour valider les modifications (File > Save). Quand le fichier «weblog.chain» est lancé, le résultat de la génération SQL se retrouve dans le répertoire «resources». Le fichier «tables.sql» est identique à la figure Figure 6.17: Résultat de la génération SQL

58 Page 58/ Configuration de la génération fichiers «properties» Acceleo incorpore un mécanisme de fichiers «properties», pour paramétrer les générations en fonction des besoins clients : par exemple le nom des répertoires et des packages. Ce mécanisme va être mis en oeuvre pour pouvoir paramétrer le nom des packages dans le projet Weblog Création du fichier «properties» par défaut Dans un esprit de structuration, il faut créer un nouveau package «org.acceleo.modules.uml2.utils» dans le répertoire «src» du projet «free.uml2.gen.java». L'ajout du fichier «properties» dans ce nouveau package s'effectue par la sélection du menu «New > File». Il suffit d'entrer le nom «config.properties» dans l'assistant puis cliquer sur «Finish» (cf figure 6.18). Figure 6.18: Un nouveau package utiltaire pour le module JSP/JDBC Ajouter dans ce fichier les clés : package.format=com.enterprise project.name=sample Adaptation des générateurs Les valeurs de ces clés seront utilisées pour former le nom des packages. Afin d'utiliser ces clés, il est bon de créer un nouveau générateur dans le même package : «org/acceleo/modules/uml2/utils/config.mt». Après avoir supprimé de ce générateur le script créé par défaut, ajouter le script suivant : <%script type="uml2.class" name="packageformat"%> <%getproperty("package.format")%>.<%getproperty("project.name")%> Ce script utilise le service «getproperty(«key»)» pour récupérer la valeur de la clé «key». Il n'est pas nécessaire de spécifier le fichier «properties» qui contient la clé recherchée, Acceleo cherche dans les fichiers à côté du fichier «Chain» lors de la génération puis, s'il ne trouve pas, à côté du fichier générateur. Cette spécificité permet lors de la définition de module de donner des valeurs par défaut aux clés utilisées dans le générateur lors de la mise au point, en définissant un fichier «properties» à coté du fichier du générateur, puis, lors de l'utilisation, de redéfinir ces valeurs en créant un nouveau fichier «properties» à côté de le chaîne de génération. Le script «packageformat» renvoie donc la valeur de la clé «package.format» suivie d'un point et de la valeur de la clé «project.name». En se basant sur les valeurs définies dans le fichier config.properties précédemment, le résultat de ce script est pour le moment «com.enterprise.sample». Il est maintenant possible d'utiliser ce script pour définir le nom des packages générés par le module JSP/JDBC : ouvrir le générateur «org/acceleo/modules/uml2/gen/java/dao/jdbc.mt» et ajouter la ligne d'import suivante :

59 Page 59/75 <% import import org.acceleo.modules.uml2.services.uml2services import org.acceleo.modules.uml2.services.stringservices import org.acceleo.modules.uml2.utils.config %> puis remplacer le contenu du script «jdbcpackage» (vers la fin du fichier) par le code suivant : <%script type="class" name="jdbcpackage"%> <%packageformat.trim()%>.jdbc Remarque : Le service «trim» utilisé sur le résultat de «packageformat» permet, comme en Java, de supprimer les espaces en trop qui peuvent être générés. Cela évite un mauvais formatage du code résultat. Une fois cette modification faite, le résultat peut être immédiatement consultable dans l'éditeur réflectif Acceleo : après un clic droit dans l'éditeur, sélectionner «Select Template» et cocher le fichier «/free.uml2.gen.java/src/org/acceleo/modules/uml2/gen/java/dao/jdbc.mt». L'onglet «Source» ouvert sur un élément affecté par ce générateur confirme le fait que la classe générée est bien dans le package «com.enterprise.sample.jdbc» (cf figure 6.19). Figure 6.19: Génération dans un package paramétré par un fichier properties L'éditeur réflectif permet immédiatement de mesurer l'impact du changement de la valeur d'une clé dans le fichier «properties». Si la valeur de la clé «project.name» est modifiée dans le fichier «config.properties» pour «weblog», le rechargement du générateur dans l'éditeur réflectif («Clic droit > Acceleo > Reload Template») change immédiatement le nom du package (cf figure 6.20). Figure 6.20: Impact du changement des valeurs du fichier «properties» dans l'éditeur réflectif Le changement de package appliqué pour les DAO doit maintenant être effectuer pour les DTO et les servlets afin de garder une cohérence de nommage. Pour cela, il faut ajouter comme précédemment l'import «org.acceleo.modules.uml2.utils.config» dans l'entête du template «org/acceleo/modules/uml2/gen/java/dto/dto.mt», et remplacer le contenu du script «dtopackage» par le code suivant : <%script type="uml2.class" name="dtopackage"%> <%packageformat.trim()%>.dto De même, il faut ajouter comme précédemment l'import «org.acceleo.modules.uml2.utils.config» dans l'entête du template «org/acceleo/modules/uml2/gen/java/ui/servlet.mt», et remplacer le contenu du script

60 Page 60/75 «scenariopackage» par le code suivant : <%script type="class" name="scenariopackage"%> <%-- ui struts package --%> <%packageformat.trim()%>.ihm Il est possible à nouveau d'étudier les impacts de ces modifications dans l'éditeur réflectif Acceleo. Une erreur s'est introduite dans le code généré durant ces modifications : les fichiers produits par le générateur «jdbc.mt» utilisent les classes générées par le générateur «dto.mt». L'import est statique : une génération provoquera donc une erreur de compilation sur l'import du package «org.acceleo.sample.dto». Pour résoudre ce problème, la ligne statique : import org.acceleo.sample.dto.<%name%>dto doit être remplacée par la ligne dynamique : import <%packageformat.trim()%>.dto.<%name%>dto; Quand la chaîne «weblog.chain» est relancée, les mêmes fichiers sont générés mais dans le package «com.enterprise.weblog» (cf figure 6.21). Figure 6.21: Package paramétré à la génération Agilité de la méthode reconfiguration de la génération Si un jour, l'entreprise décide de changer le standard de nommage des packages en incluant la gamme de produit de l'application générée dans le nom des packages. Tel que les générateurs sont désormais réalisés, il suffit de rajouter un fichier «new_config.properties» à côté du fichier «weblog.chain» et d'y mettre la clé «project.name» avec la valeur «web.weblog» (en supposant que la nouvelle gamme de produit est «web») (cf figure 6.22). Figure 6.22: Un nouveau fichier de configuration implique de nouveaux noms de package

61 Page 61/ Scénario 4 : Méta-modèle spécifique création et usage Jusqu'à présent, tous les tutoriels se sont déroulés sur des modèles de type UML2. Cependant, Acceleo est apte à travailler sur n'importe quel type de modèle : uml 1.4, merise voir même des modèles issus de métamodèles créés par l'utilisateur. Pour cela, EMF propose des outils permettant de créer ses propres méta-modèles. Acceleo peut appliquer des générateurs sur ces modèles. Ce tutoriel décrit le processus allant de la création d'un méta-modèle à l'application d'un générateur sur un modèle instancié Création d'un méta-modèle La première étape de ce tutoriel consiste à créer un méta-modèle de cinématique. Un méta-modèle est un modèle de modèle : il définit les concepts et les relations dans les modèles qui seront instanciés depuis ce méta-modèle. Les concepts que l'on peut rencontrer dans la modélisation de la cinématique sont : les écrans les composants graphiques dans ces écrans les actions que l'on peut déclencher depuis ces écrans Ces concepts devront donc être retranscrits dans le méta-modèle de cinématique qui va être créé Projet de méta-modèle Il faut tout d'abord créer un nouveau projet de méta-modèle : «File > New > Project...» puis «Acceleo > Metamodel Project» (cf figure 7.1). Ensuite, l'assistant de création demande de nommer le projet («fr.obeo.metamodel.cinematic») et le fichier ecore principal («cinematic.ecore»). Figure 7.1: Nouveau projet de métamodèle Un nouveau projet est créé avec un répertoire «model» contenant un sous répertoire icons et le fichier

62 Page 62/75 «cinematic.ecore». Ce fichier est le nouveau méta-modèle, il faut maintenant le compléter. Le méta-modèle est pour le moment constitué d'un package «plateform» désignant le fichier ecore, et d'un sous package «cinematic» Création du méta-modèle La première action à effectuer est de renseigner l'uri du méta-modèle : cette définition se fait dans la vue des propriétés du package «cinematic» (Clic droit > «Show Properties View»). La vue «Properties» s'ouvre avec quatre clés. La clé à renseigner est «Ns URI» : la valeur à définir est « cinematic». Il faut maintenant passer aux concepts du méta-modèle : effectuer un clic droit sur le package «cinematic» puis sélectionner «New Child > EClass». Une «EClass» représentant un concept du méta-modèle est ajoutée dans le package «cinematic». En sélectionnant cette EClass, la vue «Properties» se met à jour et comporte une clé «Name» : donner la valeur «Interface» à cette clé. Ce premier concept servira de conteneur pour les modèles. Il faut maintenant définir les écrans, les composants graphiques et les actions de la cinématique : effectuer à nouveau un clic droit sur le package «cinematic» et sélectionner «New Child > EClass». Toujours à l'aide de la vue «Properties», donner la valeur «Screen» à la nouvelle «EClass» créée. Il faut faire la même chose pour «Widget» et «Action». Le méta-modèle doit maintenant être identique à la figure 7.2. Figure 7.2: Les quatres concepts du métamodèle sont définis Il faut désormais définir les informations caractérisant ces concepts. L'interface étant juste un conteneur, aucune information particulière n'a besoin d'y être stockée. Les écrans peuvent avoir un titre. Les composants graphiques et les actions ont un nom. Ces informations sont stockées sous forme d'attributs dans les classes du méta-modèle. Pour définir le nom des écrans, il faut effectuer un clic droit sur l'élément «Screen» puis sélectionner «New Child > EAttribute» (cf figure 7.3). Figure 7.3: Ajout d'un attribut

63 Page 63/75 Dans la vue «Properties» pour cet «EAttribute», de nombreuses options peuvent être configurées ou renseignées mais deux champs sont obligatoires : le nom et le type. Étant donné que l'attribut correspond au titre de l'écran, donner la valeur «title» à la clé «name» et sélectionner la classe «EString» pour la clé «EType». L'attribut affiche désormais «title : EString» (cf figure 7.4). Figure 7.4: L'attribut «title» est nommé et typé Afin d'être en corrélation avec la définition de la cinématique réalisée au début de ce scénario, il faut ajouter un attribut «name» de type «EString» aux éléments «Widget» et «Action». Le méta-modèle doit maintenant être similaire à celui de la figure 7.5. Figure 7.5: Les informations à stocker des concepts La dernière étape de la création de ce méta-modèle consiste à définir les relations entre ces différents concepts : l'interface contient des écrans qui eux contiennent des composants graphiques et des actions. Les écrans peuvent être également directement liés entre eux. Les relations de contenance ou simplement de liaison se représentent de la même manière : une référence est définie dans un conteneur et caractérise une relation vers des objets du type donné. Pour définir la relation de contenance entre l'interface et les écrans, il suffit d'ajouter une nouvelle «EReference» comme enfant de l'élément «Interface» (clic droit sur «Interface» > New Child > EReference»). Comme pour les attributs, de nombreuses informations peuvent être définies pour les références mais dans le cadre de ce tutoriel seules quelques unes sont utiles : donner la valeur «screens» à la propriété «Name» ; définir le type «Screen» pour la propriété «EType» ; donner la valeur «true» à la propriété «Containment» ; laisser la valeur «0» à la propriété LowerBound ; donner la valeur «-1» à la propriété UpperBound. Une référence «screens» est ainsi définie pour le type «Interface». Cette référence concerne le type

64 Page 64/75 «Screen», elle a une quantité minimale 0 et quantité maximale illimitée d'éléments (-1 signifie illimitée). L'interface pourra donc stocker un nombre quelconque d'écrans et cette relation sera accessible par le mot clé «screens». Le métamodèle doit maintenant être identique à la figure 7.6. Figure 7.6: La référence «ecrans» est définie pour l'interface La même procédure doit être réalisée pour les références «widgets» et «actions» de la classe «Screen». Les deux références doivent avoir la clé «UpperBound» à «-1» (un écran peut stocker plusieurs composants et donner accès à plusieurs opérations) et la clé «Containment» à «true». Une dernière relation reste à définir : les liens directs entre écrans. Il ne s'agit plus ici d'une relation de contenance (Containment à «false») : un écran est lié à d'autres écrans, il ne contient pas d'autres écrans. Pour réaliser ce lien, créer une nouvelle «EReference» à la classe «Screen», nommer cette référence «directlinks», mettre la clé «EType» à «Screen» et la clé «UpperBound» à «-1» (un écran peut être lié à 0 ou plusieurs écrans). Le méta-modèle doit maintenant être identique à la figure 7.7. Figure 7.7: Métamodèle de cinématique dans son état final Le méta-modèle doit être conforme à EMF afin de pouvoir être utilisé par les outils basés sur ce framework (comme Acceleo). Pour s'assurer de la correction du méta-modèle, il suffit d'effectuer un clic droit sur le package «cinematic», puis de sélectionner «Validate». Un message d'eclipse confirmera que le méta-

65 Page 65/75 modèle est effectivement conforme à EMF (cf figure 7.8). Figure 7.8: Le métamodèle est conforme EMF Le méta-modèle est donc pleinement exploitable avec Acceleo. La prochaine étape consiste à définir un générateur pour les modèles instanciés depuis ce méta-modèle.

66 Page 66/ Création de l'éditeur de modèles Le méta-modèle est conforme à EMF qui est capable de générer des éditeurs graphiques de méta-modèle. La création de l'éditeur s'effectue à l'aide d'un clic droit sur le méta-modèle et d'une sélection de «Acceleo > Generate Editor» (cf figure 7.9). Figure 7.9: Génération de l'éditeur Une fois la barre de progression Eclipse disparue, deux nouveaux projets sont créés dans le workspace. Un projet «fr.obeo.metamodel.cinematic.edit» et un second «fr.obeo.metamodel.cinematic.editor». Afin d'exploiter le résultat de cette génération, double cliquer sur le fichier «plugin.xml» à la racine du projet «fr.obeo.metamodel.cinematic.editor». La fenêtre ouverte sur «plugin.xml» dispose d'un onglet «Overview». En cliquant sur le lien «Launch an Eclipse application» de cet onglet, un nouvel Eclipse se lance avec un éditeur de modèle conforme au méta-modèle défini précédemment (cf figure 7.10). Figure 7.10: Lancement de l'éditeur de modèle Pour utiliser cet éditeur, créer un nouveau projet : «File > New > Project...» puis «General > Project». Après avoir nommé ce projet «fr.obeo.sample.demo.cinematic.model» et créé dans ce projet un nouveau répertoire («Clic droit sur le projet > New > Folder») «model», il faut lancer l'assistant de création de fichier (clic droit sur le répertoire «model» > «New > Other...»). Dans la fenêtre de sélection d'assistant, une nouvelle entrée permet d'accéder au nouvel éditeur de modèles : «Example EMF Model Creation Wizards > Cinematic Model». En la sélectionnant, l'étape suivante demande comment nommer le modèle, entrer le nom «sample.cinematic» pour pouvoir passer à l'étape de finalisation. Celle-ci demande de sélectionner un type : ce type sera l'élément racine du modèle. L'élément «Interface» constituant l'élément racine des modèles de cinématique, il faut sélectionner ce type pour le champ «Model object». Le nouveau modèle «sample.cinematic» peut maintenant être ouvert (cf figure 7.11).

67 Page 67/75 Figure 7.11: Nouveau modèle de cinématique Il est désormais possible, à l'aide d'un clic droit sur «New Child» ou «New Sibling», de créer des modèles conformes au méta-modèle de cinématique. Le processus de création étant analogue à celui d'un fichier «Chain». L'utilisation de cet éditeur constitue le premier moyen de créer des modèles conforment au méta-modèle de cinématique. Le problème est que ces modèles sont créés dans un workspace différent du workspace de travail normal, ce qui a pour conséquence de fragmenter la localisation des données. Un autre moyen d'obtenir un modèle conforme à ce méta-modèle dans le même workspace est la création d'instance dynamique Création d'un modèle conforme au méta-modèle de cinématique Il faut retourner dans la première instance d'eclipse (il est possible de fermer la deuxième instance qui avait été lancée). Un nouveau projet simple «fr.obeo.sample.demo.cinematic.model» doit être créé afin d'accueillir le modèle qui va être réalisé. Remarque : Le nom de projet est identique à celui de la deuxième instance d'eclipse. Il n'y a pas de problème d'interférence entre les deux projets étant donné qu'ils se trouvent dans deux workspaces différents. Pour créer une nouvelle instance de modèle, il faut effectuer un clic droit dans la fenêtre du métamodèle «cinematic», sur la classe «Interface», puis sélectionner «Create Dynamic instance» (cf figure 7.12). Figure 7.12: Création d'un modèle depuis le métamodèle de cinématique Une fenêtre apparaît pour créer le nouveau modèle : nommer ce fichier «sample.xmi» et le placer dans le répertoire «model» du projet «fr.obeo.sample.demo.cinematic.model» (cf figure 7.13).

68 Page 68/75 Figure 7.13: Création du modèle «sample.xmi» dans le bons répertoire «model» Une nouvelle fenêtre «sample.xmi» s'ouvre et l'objet «Interface» est considéré comme l'élément racine du modèle. Il ne reste qu'à définir les écrans ainsi que leurs relations. Le modèle exemple à construire est une interface constituée de quatre écrans : un premier écran d'accueil permet d'accéder à deux écrans formulaires. Le premier écran formulaire demandera le sexe de l'utilisateur et réalisera une action de personnalisation. Le deuxième écran formulaire demandera l'age de la personne et réalisera une action d'enregistrement. Ce deuxième écran permettra en plus d'accéder à un écran de statistique. Depuis ce dernier écran, on ne pourra revenir que sur l'écran d'analyse de l'âge. À l'aide du menu contextuel «New Child > Screen» de l'objet «Interface», il faut créer quatre écrans dans l'interface du modèle (cf figure 7.14). Les écrans possèdent une propriété «title» permettant de leur donner un titre. Ils portent les noms «Welcome», «Gender Form», «Age Form» et «Age Statistics». Figure 7.14: l'interface Création d'écran dans Une fois les quatre écrans créés, le modèle doit être identique à celui de la figure 7.15.

69 Page 69/75 Figure 7.15: Les quatre écrans de l'interface Il faut maintenant définir les composants des écrans. Le premier écran formulaire possédera un composant graphique servant à récupérer le sexe de l'utilisateur. Le second écran formulaire possédera lui aussi un composant graphique servant à récupérer l'âge de l'utilisateur. L'ajout de ces composants se fait de manière analogue à l'aide du menu contextuel «New Child > Widget» des objets écrans (cf figure 7.16). Comme il vient d'être défini, l'écran «Gender Form» a un composant nommé «Sex» et l'écran «Age Form» un composant «Age». Figure 7.16: Création de composant graphique Quand les deux composants sont créés, le modèle doit être identique à celui de la figure Figure 7.17: Les écrans avec leurs composants graphiques

70 Page 70/75 Quand l'utilisateur a entré les renseignements requis dans un écran formulaire, il doit déclencher une action. Il a été défini que, dans ce modèle, l'écran de genre avait une action de personnalisation et que l'écran d'âge avait une action d'enregistrement. De manière analogue à la création des composants graphiques, l'ajout d'action passe par l'utilisation du menu contextuel «New Child > Action» des objets «Screens». De cette façon, il faut ajouter une action «Personalize» à l'écran «Gender Form» et ajouter une action «Save» à l'écran «Age Form». Le modèle est à présent identique à celui de la figure Figure 7.18: Les actions des écrans La dernière étape consiste à définir les liens directs entre écrans : sélectionner l'écran «Welcome» et dans la vue «Properties» cliquer sur la clé «directlinks». En cliquant sur le bouton «...» qui apparaît, la fenêtre de la figure 7.19 s'ouvre. Figure 7.19: Création de liens En sélectionnant l'écran «Gender Form» et en cliquant sur «Add», un lien vers cet écran peut être ajouté. Il faut créer de la même manière un lien pour l'écran «Age Form». Il faut également ajouter des liens de «Age Form» vers «Age Statistics» et de «Age Statistics» vers «Age Form» en effectuant la même procédure.