mia-generation -manuel de l'utilisateur · mia-generation – manuel utilisateur - 3 liste des...

MIA-Generation

- Manuel de l'utilisateur -

MIA-Generation – Manuel Utilisateur - 2

Cette documentation est la propriété de Mia-Software. Elle ne peut être reproduite, même partiellement, sous quelque forme que ce soit, sans autorisation écrite préalable.

Table des matières

PRESENTATION .......................................................................................................................................................7

PREAMBULE ...............................................................................................................................................................7 INTERETS D’UN GENERATEUR DE CODE ......................................................................................................................8

Temps de développement réduit ............................................................................................................................8 Qualité...................................................................................................................................................................8 Adaptabilité ...........................................................................................................................................................8 Continuité entre la modélisation et l'implémentation ............................................................................................9 Réactivité...............................................................................................................................................................9

ARCHITECTURE DE MIA-GENERATION ....................................................................................................................10 AVANTAGES LIES A MIA-GENERATION ...................................................................................................................11

Facilité d’expression du code généré ..................................................................................................................11 Java comme langage de script.............................................................................................................................11 Approche globale de la génération......................................................................................................................11 Prise en compte des cycles itératifs .....................................................................................................................11 Support des concepts objets.................................................................................................................................11 Prise en compte des profils..................................................................................................................................11 Evolutivité ...........................................................................................................................................................12

DÉMARRAGE ..........................................................................................................................................................13

MIA-GENERATION ARCHITECT .......................................................................................................................14

PRESENTATION.........................................................................................................................................................14 Concepts de base .................................................................................................................................................14 Les types de scripts..............................................................................................................................................15 L’organisation des scripts ...................................................................................................................................16

Les packages........................................................................................................................................................................16 Les types..............................................................................................................................................................................16 Les catégories ......................................................................................................................................................................16 Les scénarios .......................................................................................................................................................................16

Interface utilisateur .............................................................................................................................................17 Documentation des éléments ...............................................................................................................................19 Statuts des éléments.............................................................................................................................................19

Les statuts des scripts ..........................................................................................................................................................19 Contexte global ...................................................................................................................................................20

Affichage du contexte global...............................................................................................................................................20 Initialisation du contexte avec la ligne de commande .........................................................................................................20

Navigateur de méta-modèle.................................................................................................................................21 EDITION ...................................................................................................................................................................22

Interface Utilisateur du panneau Edition ............................................................................................................22 Chargement et sauvegarde d'éléments ................................................................................................................23 Le projet de génération .......................................................................................................................................24

Charger un projet .................................................................................................................................................................24 Sauver un projet...................................................................................................................................................................24 Créer un projet .....................................................................................................................................................................25 Exporter un projet compilé ..................................................................................................................................................25 Exporter un projet au format Standalone.............................................................................................................................25 Regrouper et Exporter les ressources d’un projet dans un dossier ......................................................................................25 Regrouper et Exporter les ressources d’un projet dans une archive zip ..............................................................................26

Les packages .......................................................................................................................................................27 Créer et éditer un package ...................................................................................................................................................28



Modifier les propriétés d'un package...................................................................................................................................28 Resynchroniser un package .................................................................................................................................................29 Comparer des packages .......................................................................................................................................................29

Les types ..............................................................................................................................................................31 Les catégories......................................................................................................................................................32 Les scripts............................................................................................................................................................33

Liste des scripts ...................................................................................................................................................................33 Propriétés des scripts ...........................................................................................................................................................34 Créer et éditer un Text Template .........................................................................................................................................39 Créer et éditer un File Template ..........................................................................................................................................41 Créer et éditer des délimiteurs de code utilisateurs .............................................................................................................43 Créer et éditer une précondition ..........................................................................................................................................47 Créer et éditer une Macro ....................................................................................................................................................48 Créer et éditer un Service ....................................................................................................................................................50 Fonctionnalités d’édition .....................................................................................................................................................51 Naviguer vers un script........................................................................................................................................................53 Réorganiser des scripts ........................................................................................................................................................55 Tester unitairement les scripts .............................................................................................................................................56 Gérer les conflits de chargement .........................................................................................................................................58

Rechercher un script ...........................................................................................................................................60 Recherche à partir de ses propriétés ....................................................................................................................................61 Recherche des scripts en erreur ...........................................................................................................................................63 Recherche des scripts portant le même nom........................................................................................................................63 Recherche des scripts appelés..............................................................................................................................................64 Recherche des scripts appelants...........................................................................................................................................64 Recherche des références à un script appelé........................................................................................................................64

Les scénarios .......................................................................................................................................................65 Créer un scénario .................................................................................................................................................................66 Visibilité d'un scénario ........................................................................................................................................................66 Sauver un scénario...............................................................................................................................................................66 Charger un scénario .............................................................................................................................................................66 Ajouter et supprimer des éléments de scénario....................................................................................................................67 Définir les scripts d'une description de génération ..............................................................................................................69 Définir les paramètres d’une transformation de modèle......................................................................................................72

Les profils............................................................................................................................................................74 Créer et éditer un profil .......................................................................................................................................................75 Ajouter un type ....................................................................................................................................................................76 Déplacer un type..................................................................................................................................................................76 Supprimer un type ...............................................................................................................................................................77 Chargement de modèles tenant compte du profil ................................................................................................................77 Création de scripts sur des types du profil ...........................................................................................................................77

Les plugins ..........................................................................................................................................................78 Créer un plugin ....................................................................................................................................................................78 Administrer les plugins........................................................................................................................................................79 Editer ou charger un plugin .................................................................................................................................................79 Recharger un plugin.............................................................................................................................................................80 Décharger un plugin ............................................................................................................................................................80 Notion de chemin menant à un menu ..................................................................................................................................80 Ajouter un élément de menu dans un menu contextuel existant..........................................................................................83 Ajouter un séparateur de menu dans un menu contextuel existant ......................................................................................83 Ajouter un menu dans un menu contextuel existant ............................................................................................................84 Positionner un élément ........................................................................................................................................................84 Notion de plugin pré-requis .................................................................................................................................................86 Utiliser les expressions régulières .......................................................................................................................................86 Liste des menus contextuels actuellement personnalisables................................................................................................87

GENERATION............................................................................................................................................................91 Généralités ..........................................................................................................................................................91 Chargement des modèles.....................................................................................................................................92

Généralités...........................................................................................................................................................................92 Importer un modèle depuis un AGL....................................................................................................................................93 Synchroniser le modèle .......................................................................................................................................................93 Consulter un modèle............................................................................................................................................................94

Génération par scénario grâce à un lanceur.......................................................................................................95 Générations unitaires ..........................................................................................................................................97

Créer une génération unitaire...............................................................................................................................................97



Sélection des scripts.............................................................................................................................................................98 Sélection des objets source ..................................................................................................................................................98

Options de génération .......................................................................................................................................100 Options générales de génération........................................................................................................................................100 Options du contexte ...........................................................................................................................................................101 Options des fichiers ...........................................................................................................................................................103 Options de rapport de génération.......................................................................................................................................103 Paramètres de transformation ...........................................................................................................................................105

Consulter le résultat d'une génération...............................................................................................................106 Détection des erreurs de génération..................................................................................................................107

Résolution des erreurs de génération .................................................................................................................................107 Rapport de génération.......................................................................................................................................108 Rapport de génération.......................................................................................................................................108

Contenu d’un rapport de génération ..................................................................................................................................108 Créer un rapport de génération ..........................................................................................................................................109 Consulter le rapport de génération courant........................................................................................................................110 Charger un rapport de génération ......................................................................................................................................111 Sauver un rapport de génération ........................................................................................................................................111

Trace de génération...........................................................................................................................................112 Trace de transformation.....................................................................................................................................................113 Sauver une trace de génération ..........................................................................................................................................113

Points d’arrêt ....................................................................................................................................................114 Opérations de base sur un point d’arrêt .............................................................................................................................114 Gérer l’ensemble des points d’arrêt d’un projet ................................................................................................................115 Déboguer en utilisant les points d’arrêt .............................................................................................................................115 Point d’arrêt conditionné ...................................................................................................................................................117

APIS ET NOTIONS AVANCEES ..................................................................................................................................118 Syntaxe des scripts Java ....................................................................................................................................118

La variable current.............................................................................................................................................................118 La variable context ............................................................................................................................................................118 Les accesseurs ...................................................................................................................................................................121 Les appels de scripts ..........................................................................................................................................................122 La méthode action .............................................................................................................................................................123 La méthode getString.........................................................................................................................................................123 La méthode getList ............................................................................................................................................................124 Les méthodes de conversion de type .................................................................................................................................125 La méthode apply ..............................................................................................................................................................127 La méthode collect.............................................................................................................................................................128 La méthode select ..............................................................................................................................................................129 La méthode detect..............................................................................................................................................................130 La méthode reject ..............................................................................................................................................................131 La méthode sort .................................................................................................................................................................132 La méthode superAction....................................................................................................................................................133 La méthode getPropertyValue ...........................................................................................................................................134

Appel des scripts avec paramètres ....................................................................................................................135 Nommage des paramètres..................................................................................................................................................135 Typage des paramètres ......................................................................................................................................................135 Appel des scripts avec paramètres depuis les templates ....................................................................................................135 Utilisation des paramètres dans les scripts Java : macros et services ................................................................................138 Accès à des composants Java externes depuis MIA-Generation .......................................................................................139

Gestion avancée des modèles ............................................................................................................................140 Profils des modèles UML ..................................................................................................................................................140 Particularités de l'import XMI ...........................................................................................................................................140 Particularités de l'import Rational Rose ............................................................................................................................141 Développer des imports de modèles spécifiques ...............................................................................................................142

Exploitation du rapport de génération dans les scripts .....................................................................................145 Accès au rapport de génération..........................................................................................................................................145 L’objet Report ...................................................................................................................................................................146 Les objets ReportGeneratedFile ........................................................................................................................................146 Les objets ReportModelFile, ReportPackage, ReportScenario, ReportProfile ..................................................................147 Les objets ReportProject....................................................................................................................................................147 Le type ReportComparisonStatus ......................................................................................................................................147 Le type ReportGenerationStatus........................................................................................................................................147

MIA-GENERATION DEVELOPER.....................................................................................................................148



PRESENTATION.......................................................................................................................................................148 Concepts de base ...............................................................................................................................................148 Interface Utilisateur ..........................................................................................................................................149

GENERATION..........................................................................................................................................................151 Création d'un lanceur........................................................................................................................................151

Sélection d'un projet ..........................................................................................................................................................151 Sélection du scénario de génération ..................................................................................................................................151 Sélection du modèle...........................................................................................................................................................151 Synchroniser le projet ........................................................................................................................................................152 Synchroniser le modèle .....................................................................................................................................................152 Options de génération........................................................................................................................................................152

Lancement de la génération ..............................................................................................................................152 Consulter le résultat d'une génération...............................................................................................................152

MODE SILENCIEUX .................................................................................................................................................152

MODULE ANALYSIS............................................................................................................................................153

PRESENTATION.......................................................................................................................................................153 STATUT DES FICHIERS GENERES .............................................................................................................................154 PORTIONS DE CODE ................................................................................................................................................155 ALERTES ................................................................................................................................................................158

Balises non regénérées ......................................................................................................................................158 Anomalie suspecte .............................................................................................................................................159 Fichiers non regénérés ......................................................................................................................................160

METRIQUES............................................................................................................................................................161 Statistiques de génération ..................................................................................................................................................162

ACTIVATION DU MODULE.......................................................................................................................................162

LIGNE DE COMMANDE......................................................................................................................................163

PRESENTATION.......................................................................................................................................................163 SELECTION D'UN PROJET.........................................................................................................................................164

Mode graphique ................................................................................................................................................164 Mode silencieux.................................................................................................................................................165

MIA-Generation Developer...............................................................................................................................................165 MIA-Generation Architect.................................................................................................................................................166

GESTION DU RAPPORT DE GENERATION ..................................................................................................................167 PARAMETRES DE TRANSFORMATION ......................................................................................................................167 SURCHARGE DES PREFERENCES UTILISATEUR.........................................................................................................168 VARIABLES DU CONTEXTE DE GENERATION ...........................................................................................................169

PRÉFÉRENCES......................................................................................................................................................170

PRÉSENTATION.......................................................................................................................................................170 PRÉFÉRENCES GÉNÉRALES .....................................................................................................................................171 PRÉFÉRENCES D'IMPORT.........................................................................................................................................172 PREFERENCES DES SCRIPTS ....................................................................................................................................173

Textes par défaut des scripts .............................................................................................................................174 Délimiteurs de Scripts .......................................................................................................................................174

PREFERENCES DE TRANSFORMATION......................................................................................................................175 PREFERENCES DE NOTIFICATION ............................................................................................................................176 PREFERENCES DE RACCOURCIS...............................................................................................................................178 PREFERENCES DE CONFIGURATION.........................................................................................................................179

ENVIRONNEMENT...............................................................................................................................................181

PRESENTATION.......................................................................................................................................................181 MIA-GENERATION.................................................................................................................................................181

Répertoire bin....................................................................................................................................................181 Répertoire compiler ...........................................................................................................................................................181 Répertoire lib .....................................................................................................................................................................181 Répertoire resources ..........................................................................................................................................................181

Répertoire flexlm ...............................................................................................................................................181 Répertoire examples ..........................................................................................................................................181 Répertoire generation........................................................................................................................................182

MIA-Generation – Manuel Utilisateur - Présentation 6


Répertoire help..................................................................................................................................................182 Répertoire log....................................................................................................................................................182 Répertoire plugins .............................................................................................................................................182 Répertoire tools/lib............................................................................................................................................182

META-MODELES.....................................................................................................................................................182

ANNEXE 1...............................................................................................................................................................183

OPTIONS UTILISATEUR ...........................................................................................................................................183 Module Analysis................................................................................................................................................................183 Model Browser ..................................................................................................................................................................183 Resultats de generation......................................................................................................................................................183 Configuration.....................................................................................................................................................................183 Options générales ..............................................................................................................................................................184 Options de génération........................................................................................................................................................184 Options de synchronisation................................................................................................................................................185 Options de rapport de génération.......................................................................................................................................185 Options des scripts.............................................................................................................................................................185 Options de transformation .................................................................................................................................................185



Présentation

Préambule MIA-Generation est un outil qui fait partie de la famille des générateurs de code. Contrairement à la plupart des outils de ce type, il n'est pas directement intégré à un outil de modélisation. C'est ce qui permet à MIA-Generation d'être totalement ouvert et adaptable à n'importe quel outil de modélisation et domaine d'application.

En standard, MIA-Generation est livré avec un analyseur de fichiers XMI, format standard de l'OMG (Object Management Group, www.omg.org) d'échange de données.

Outre cette ouverture en amont, MIA-Generation est aussi totalement ouvert en aval. En effet, grâce à la puissance d'expression des scripts de génération, MIA-Generation permet, de manière très simple, de s'adapter à n'importe quelle cible de génération.

http://www.omg.org



Intérêts d’un générateur de code Un générateur de code intervient essentiellement lors de la phase de conception d’une application. Il offre un certain nombre d’intérêts dont voici les principaux :

Temps de développement réduit Il arrive fréquemment que l’on ait à écrire du code systématique sur un grand nombre d’entités (les accesseurs de toutes les classes par exemple). Le code est alors presque identique à chaque fois : seuls quelques caractères changent (le nom de l’entité par exemple). Lorsque ce type de code est à reproduire un très grand nombre de fois, le fait de le générer permet de gagner un temps non négligeable.

Qualité Lorsque le code est généré, on réduit considérablement le nombre d’erreurs. En effet, on élimine toutes les fautes de frappes, toutes les fautes de copier-coller (technique très utilisée sans générateur), tous les oublis, etc.… Tous ces types d’erreurs ne sont pas forcément visibles au premier coup d’œil, d’où le risque d’en laisser dans le code final.

Par contre dans le cas de la génération, si l’on fait une faute lors de l’écriture du script, la faute est généralement répercutée sur toutes les entités : la détection est donc rapide. Une correction du script et une régénération complète permettent d’éliminer l’erreur. Enfin, si le code est généré, on assure un format unique de présentation, ce qui permet de rendre le code plus lisible, et donc plus facile à maintenir.

Adaptabilité Lorsque l’on commence la conception, on n’a pas nécessairement toutes les bonnes idées dès le départ. Deux possibilités se présentent alors au développeur :

Commencer rapidement la conception, au risque de faire de mauvais choix, et d’avoir ensuite à réécrire une partie du code.

Repousser le début de la conception tant que tous les concepts n’ont pas été complètement validés, au risque de retarder les autres phases du projet.

Lorsque l’on dispose d’un générateur de code, on est moins confronté à ce dilemme, puisqu’une idée de conception qui arrive tardivement peut être facilement intégrée, et ce quelque soit le nombre d’entités impactées. On peut ainsi commencer la conception même si tous les concepts ne sont pas complètement arrêtés, quitte à revenir ultérieurement sur certaines parties du code. De cette manière, il est possible de livrer rapidement une première version, avec laquelle il sera plus aisé de détecter les éventuels problèmes.



Continuité entre la modélisation et l'implémentation Dans tout projet de taille significative, la modélisation constitue une part importante de la charge. Cette modélisation a pour but, entre autres, d’obtenir un modèle de conception qui va guider les développeurs dans leur tâche de réalisation. Tout serait parfait si, une fois la modélisation terminée, on était certain d’avoir pensé à tout et d’avoir tout modélisé comme il le fallait. Or, il est rare qu’une fois la phase d'implémentation commencée, on ne revienne plus sur la phase de modélisation. En effet, outre les oublis éventuels, on n’est jamais complètement à l’abri d’une évolution des spécifications et des attentes de futurs utilisateurs.

Lorsque l'implémentation est commencée, toute évolution implique une modification à la fois du modèle et du code déjà écrit. Cette double intervention a un coût très important car c'est une opération fastidieuse qui prend du temps et de l'énergie. Lorsque les délais sont courts, le risque existe que les modifications ne soient plus effectuées que sur le code et qu'elles ne soient pas répercutées sur le modèle. Dans ce genre de cas (très fréquents) le modèle est petit à petit délaissé, puis complètement abandonné lorsque les différences sont trop importantes.

Avec un outil de génération, c’est le modèle qui reste la référence tout au long du cycle de vie du projet. En effet, les modifications peuvent être reportées sur le modèle (et non plus directement dans le code) , à partir duquel on peut toujours régénérer le code nécessaire. De cette façon, le modèle n’est plus seulement une représentation de ce qui doit être conçu, mais devient aussi une représentation de ce qui est conçu (voire de ce qui a été conçu, ce qui est très utile lors de la phase de maintenance).

Réactivité Globalement l’utilisation d’un générateur de code permet une meilleure réactivité lors de la phase d'implémentation.



Architecture de MIA-Generation L'architecture de MIA-Generation est complètement ouverte. Elle est entièrement articulée autour d'un besoin : celui de mettre en relation d’une part un modèle résultant de la phase d’analyse, et d’autre part des scripts de génération qui traduisent des choix de conception. Au moyen de cette association, MIA-Generation génère des fichiers.

Le type des fichiers générés est complètement ouvert et laissé au libre choix de l’utilisateur de l’outil :

Exemples :

Code source (C++, Java, CSharp, Delphi, …)

Documentation (liste des classes du modèle, contrôles de cohérence, …)

Migration vers un autre AGL

Modèle

UML

Scénario

de

génération

J2EE

C++

...

Fichiers

générés

Poseidon

Rose

MagicDraw

RSM

Modèle

(

fichier d’échange

)

Java

Java

java

Java

Java

JSP

Java

Java

Serv

lets

Java

Java

.

Cpp

Java

Java

.h

Java

Java

make

Objecteering

XMI

Java

Java

Figure 1 – Architecture de l'outil

MIA-Generat ion for UML est vendu avec des analyseurs qui permettent d'importer les modèles saisis avec les principaux AGL du marché :

Tout AGL supportant le format UML1.x-XMI (Standard défini par l’Object Management Group) :

- Rhapsody (I-Logix),

- Mega Development (Mega International)

- Together (TogetherSoft)

- Objecteering (Softeam)

- Poseidon (Gentleware)

- MagicDraw for UML (No Magic)

Rational Rose (IBM)

Rational Software Modeler (IBM) pour UML2



Avantages liés à MIA-Generation MIA-Generation n’est pas le seul générateur de code existant sur le marché. En effet, la plupart des AGL possèdent aussi un générateur de code. Cependant, par rapport à ceux-ci, MIA-Generation possède un certain nombre d’atouts :

Facilité d’expression du code généré L’éditeur de scripts est de type WYSIWYG (What You See Is What You Get). Ainsi, il suffit de saisir le code qui doit être généré (parsemé de noms de macros) au lieu de le programmer. La création des scripts est ainsi grandement facilitée, puisqu’il est possible de les concevoir grâce à des copier-coller issus du code déjà écrit pour une classe.

Java comme langage de script Dans un script, tout ne peut pas être exprimé de manière WYSIWYG. C’est notamment le cas de la partie variable du script généré (le nom de l’entité par exemple). On fait alors appel à une macro écrite en JAVA™.

L’utilisation de ce langage objet puissant évite l’apprentissage d’un langage propriétaire de type BASIC, solution généralement proposée par les AGL.

Approche globale de la génération MIA-Generation vous permet de définir vous-même des scénarios de génération, dans lesquels vous pourrez regrouper plusieurs types de génération différentes qui doivent s’effectuer ensemble (en C, par exemple, vous pouvez avoir à générer en même temps les .c et les .h). Il est ainsi possible avec MIA-Generation de générer tous les fichiers nécessaires en une seule fois.

Prise en compte des cycles itératifs Les fichiers générés peuvent être enrichis par du code spécifique écrit à la main. MIA-Generation peut conserver ce code lors des générations ultérieures.

Support des concepts objets Les scripts qui sont créés avec MIA-Generation sont rattachés à des concepts objets. Ainsi, on bénéficie par exemple des notions d’héritage, de polymorphisme et de packages. Ceci permet de structurer efficacement et proprement les scripts écrits. On évite de cette façon de se retrouver avec des fichiers « fourre-tout » contenant des scripts n’ayant aucun rapport les uns avec les autres.

Prise en compte des profils La notion de profil, apportée par UML 1.4, est un moyen qui permet de définir une extension d'UML. Un profil est spécifié par la liste des types UML à utiliser, une liste de stéréotypes, une liste de tagged-values et une liste de contraintes.

MIA-Generation supporte cette notion de Profil, et étend son usage à tout méta-modèle : la notion de Profil peut être vue comme un moyen d'étendre facilement un méta-modèle. Chaque utilisateur peut définir sa propre liste de nouvelles classes. Il pourra alors définir des scripts directement sur ces classes, et les modèles importés pourront tenir compte de ces classes lors de l'instanciation des objets.



Evolutivité Nous utilisons nous même MIA-Generation pour la conception d’une grande partie du code de MIA-Generation. MIA-Generation peut donc facilement évoluer pour s’adapter à des besoins spécifiques (votre propre méta-modèle par exemple).

MIA-Generation – Manuel Utilisateur - Démarrage 13


Démarrage

Au 1er démarrage de MIA-Generation, une boîte de dialogue vous invite à choisir la configuration avec laquelle vous souhaitez travailler. Par configuration, on entend un couple édition / distribution. MIA-Generation propose 2 éditions et 2 distributions, respectivement :

- Architect & Developer

- Enterprise & Professional

L'édition Architect permet de concevoir un générateur, de lancer et de le tester.

L'édition Developer permet de lancer un générateur.

La distribution Enterprise propose l'ensemble des fonctionnalités de MIA-Generation tandis que la distribution Professional ne propose qu'un ensemble réduit des fonctionnalités disponibles. L'une des différences majeures concerne le module Analysis disponible uniquement avec la distribution Enterprise et qui permet notamment de visualiser facilement les différentes portions de code au sein des fichiers générés, de connaître leur statut et les différences depuis la dernière génération (Cf. Module Analysis).

Figure 2 – Sélection de la configuration

Les configurations proposées par cette boîte de dialogue correspondent aux licences dont vous disposez. Si vous ne disposez que d'un seul type de licence, alors MIA-Generation se lance automatiquement dans la configuration correspondante.

Si la licence pour la configuration sélectionnée n'est finalement pas disponible, la boîte de dialogue apparaît de nouveau pour vous proposer les choix restants.

Lors des lancements suivants, MIA-Generation tentera de se lancer en utilisant la même configuration. Il est possible de changer de configuration grâce au menu Preferences, si les licences dont vous disposez le permettent (Cf. Préférences).

La configuration peut-être également paramétrée en ligne de commande (Cf. Surcharge des préférences utilisateur).

MIA-Generation – Manuel Utilisateur - MIA-Generation Architect 14


MIA-Generation Architect

Présentation MIA-Generat ion Architect est l'application qui va vous permettre de construire un générateur sur mesure pour un contexte donné. Ce générateur est packagé sous la forme d'un projet de génération. Les tableaux suivants présentent les principaux concepts manipulés au sein d'un projet de génération.

Concepts de base

Un projet de génération regroupe un ensemble de packages et scénarios et un profil. Un projet définit un générateur, basé sur l'utilisation d'un méta-modèle, sans être lié à tel ou tel modèle physique. C'est une évaluation du générateur qui fera appel à des modèles physiques pour son exécution.

Un package regroupe un ensemble de scripts qui réalisent une génération. Les packages permettent d'organiser les scripts. Tout script est rattaché à un type du méta-modèle.

Les scripts peuvent être de deux sortes :

Les modèles de génération (ou templates). Un template est un texte qui décrit de manière visuelle, la façon dont le code doit être généré pour un type d'objet du modèle.

Les scripts écrits en Java. Il existe deux types de scripts Java : les macros pour traiter la partie variable du code généré et les services pour filtrer les objets du modèles.

A l'intérieur des packages, les scripts peuvent être organisées en catégories.

Un scénario décrit des enchaînements d'évaluation de scripts. Ces enchaînements sont organisés en descriptions de générations. Un scénario peut également appeler d'autres scénarios. Il peut aussi transformer un modèle par un appel au logiciel Mia-Transformation.

Un profil est une façon simple de personnaliser un méta-modèle en ajoutant des types.

Le modèle ne fait pas partie du projet mais constitue le paramètre d'entrée principal de votre générateur.

Le rapport de génération est un outil permettant de tracer les modifications successives, manuelles ou dues à la génération, entre vos fichiers générés.



Les types de scripts Les scripts permettent de décrire comment du texte peut être généré à partir des objets du modèle. MIA-Generation met à votre disposition deux types de scripts de générations :

les modèles textuels de génération ou templates : l’éditeur de templates est de type WYSIWYG (What You See Is What You Get). Ainsi, il suffit de saisir le code qui doit être généré (parsemé d'appels à d'autres scripts) au lieu de le programmer.

Figure 3 - Exemple de Text Template

Les scripts écrits en JAVA™ : les macros et les services. Tout ne pouvant pas être exprimé de manière WYSIWYG, ce sont ces scripts Java qui vont permettre d'obtenir la partie variable du script généré.

Figure 4 - Exemple de Macro

Chaque script est rattaché à un type particulier du méta-modèle (par exemple au type UMLClass dans le cas du méta-modèle UML). Il ne pourra donc s'appliquer que sur des objets de ce type, ou d'un sous-type.

Un text template est un modèle textuel de génération. Le texte d’un template est constitué :

d’éléments textuels qui seront reproduits tels quels dans le texte généré.

de noms de scripts dont le résultat, au moment de l'évaluation, sera inséré dans le texte généré.

Il est possible de délimiter dans un template une zone de texte qui pourra être modifiée à la main dans le fichier généré, et qui ne devra pas être écrasée lors d’une future génération. Pour ce faire, il faut utiliser les propriétés BeginTag et EndTag.

Un template peut déclarer une propriété Precondition. Une précondition est une macro Java qui renvoie un booléen. Le template ne sera évalué que si précondition renvoie vrai.

Un file template est un text template auquel on a ajouté une propriété Filename. Cette propriété permet de spécifier le nom du fichier dans lequel le résultat du file template doit être sauvegardé.

Une macro est une partie de code écrite en Java, qui est évaluée pour un objet du modèle et dont le résultat est du texte ou n'importe quel objet Java.



Les services sont des macros particulières qui permettent de renvoyer des objets du modèle. Ils ont pour fonction de sélectionner, filtrer les différents objets du modèle.

L’organisation des scripts

Les packages

Chaque script, en plus d’être rattaché à un type d’objet, doit être rattaché à un package. Dans un package, il est possible de regrouper des scripts rattachés à des types d’objets différents.

Le but est de pouvoir organiser dans des entités différentes les scripts écrits pour des besoins différents. Cela permet d'organiser les scripts par niveaux : des plus génériques aux plus spécifiques.

GénériqueGénérique

IHMC++IHMC++

JavaJavaC++C++

Modèle métierC++

Modèle métierC++

Modèle métierJava

Modèle métierJava

prérequis

Figure 5 - Exemples de packages

En standard, MIA-Generation fournit un package (non modifiable) appelé "System". Ce package contient un certain nombre de macros et de services de base propres au méta-modèle utilisé.

Les types

Les types d'objets sont les éléments proposés par le méta-modèle, sur lesquels il est possible de créer des scripts. Les scripts qui sont créés avec MIA-Generation sont ainsi rattachés à des concepts objets. On bénéficie alors, par exemple, des notions d’héritage et de polymorphisme.

Les catégories

Lorsque le nombre de scripts commence à être très important, il peut être utile de les classer au sein de catégories. Vous pouvez alors créer autant de catégories que vous le souhaitez. En standard, il existe au moins une catégorie nommée "default" pour chaque type d'objets (cette catégorie n'est pas supprimable).

Les scénarios

Le plus souvent la génération de tous les fichiers résulte de l'application de plusieurs scripts sur des objets différents du modèle. Par exemple un premier script appliqué sur le modèle, un deuxième script sur toutes les classes persistantes et un troisième script sur toutes les classes non persistantes. Pour éviter d'avoir à effectuer manuellement les trois générations successives, avec tous les risques d'erreur possibles (oubli d'une génération, erreur dans le choix d'un script, …), vous pouvez créer un scénario qui regroupe une liste de générations.

Une génération est décrite par l'application d'une liste de scripts sur les objets renvoyés par un service donné, appliqué sur toutes les instances d'un type d'objets.

Un scénario peut lui-même servir à construire d'autres scénarios.

Un scénario peut en outre intégrer une ou plusieurs étapes de transformation de modèle, les éléments de scénario suivants s'appliquent alors sur le résultat de ces transformations.



Interface utilisateur

L'interface utilisateur de MIA-Generation est composée de plusieurs parties :

Une barre de menus

Une barre d'icônes

Un navigateur de projet, sur la gauche

Une zone de documentation de l'élément sélectionné dans le navigateur de projet, en

Une zone d'édition de l'élément sélectionné dans le navigateur de projet, sur la droite

Figure 6 - Interface Utilisateur MIA-Generation Architect



Voici les opérations accessibles avec la barre d'icônes :

Icône Description

Création d'un élément (projet, package, etc.)

Chargement d'un élément (projet, package, etc.)

Sauvegarde de l'élément sélectionné dans le navigateur de projet

Création d'un nouveau projet

Chargement d'un projet

Rechargement du projet courant

Création d'un nouveau scénario

Création d'un nouveau package

Création d'un nouveau profil

Création d'un nouvel appel de scénario

Création d'un nouveau plugin

Création d'une nouvelle description de génération

Création d’une nouvelle description de transformation

Création d'une nouveau template

Création d'un nouveau file template

Création d'une nouvelle macro

Création d'un nouveau service

Chargement d'un modèle

Rechargement du modèle sélectionné dans le navigateur de projet

Création d'un nouveau lanceur de génération

Lancement de la dernière génération. Un historique des dernières générations lancées est conservé, accessible par un menu déroulant.

Sélection de l'élément précédent

Sélection de l'élément suivant



Documentation des éléments Tout élément de projet peut être documenté. La fenêtre de documentation Documentation est toujours visible et éditable. Elle affiche la documentation de l'élément en cours de sélection.

Figure 7 - Affichage de la documentation de l'élément sélectionné

Statuts des éléments Tout élément de projet possède un statut qui indique si l'objet est valide ou s'il comporte une erreur. Deux statuts sont possibles :

ERROR : une propriété de l'élément est invalide. L'élément est alors affiché en rouge dans le navigateur de projet.

WARNING : l'élément a soit un de ses sous-éléments en erreur, soit référence un autre élément qui a une erreur. L'élément est alors affiché en orange dans le navigateur de projet.

Un onglet Problems permet de visualiser l'erreur ou l'avertissement de l'élément sélectionné dans l'interface :

Figure 8 - Affichage de l'erreur de l'élément sélectionné

Les statuts des scripts

Au moment de la sauvegarde, si un script possède une erreur il est marqué avec le statut Error (il apparaît en rouge). Tous les scripts qui référencent directement ce script sont alors marqués avec le statut Warning (ils apparaissent en orange). Lorsque le script est corrigé il devient en statut normal et les scripts en Warning à cause de lui redeviennent eux aussi au statut normal.

Tant qu'un script est en erreur, le texte de l'erreur est consultable dans l'onglet Problems du panneau de d'édition.

Un script en Error ou en Warning ne peut être exécuté.

Un package contenant au moins un script dont le statut est Error, il apparaît en rouge. S’il ne contient pas de scripts en erreur mais au moins un script dont le statut est Warning, il apparaît en orange.

La fenêtre Problems affiche l'erreur de l'élément en cours de sélection dans le navigateur de projet.



Contexte global MIA-Generation met à disposition un contexte global de génération. Ce contexte peut contenir des informations qui seront accessibles depuis toute macro ou service, et qui peuvent être conservées entre générations successives.

MIA-Generation fournit les moyens d'accéder à ce contexte via une variable context prédéfinie dans les scripts Java (voir le chapitre "Scripts de génération").

Affichage du contexte global

MIA-Generat ion Architect permet de visualiser et de modifier le contenu de la variable context grâce à un inspecteur de contexte.

Pour afficher le contexte global, utilisez le menu principal Window > Global Context Inspector. Une boite de dialogue apparaît dans laquelle vous pouvez visualiser les couples Clé/Valeur de la variable context.

Figure 9 - Inspecteur de contexte

Suivant l’origine du couple Clé-Valeur, l’attribut Source prend les valeurs suivantes :

SOURCE DE LA CLE DESCRIPTION

SYSTEM

Clé prédéfinie dont la valeur initiale n’a pas été modifiée

OVERRIDE Clé prédéfinie dont la valeur a été surchargée par l’utilisateur

USER Clé ajoutée par l’utilisateur

L’inspecteur permet d’ajouter de nouvelles variables, de les modifier ou de les supprimer. Les valeurs prédéfinies (System) qui ne peuvent être supprimées apparaissent en grisé.

Initialisation du contexte avec la ligne de commande

Le contexte global peut être initialisé au lancement de MIA-Generation. Pour cela, il suffit de placer, en ligne de commande, la liste des variables à stocker dans le contexte (avec leur valeur, sous forme de chaînes de caractères).

Exemple : Initialisation du contexte avec la ligne de commande

-resourceDirectory c:\project\resources -version 2

Ceci a pour conséquence de placer les variables resourceDirectory = "c:\project\resources" et version = "2" dans le contexte.



Navigateur de méta-modèle Les scripts de générations se basent sur l'utilisation d'un méta-modèle. En standard, MI A-Generation est fourni avec deux méta-modèles : UML (compatible UML1.3 et UML1.4) et UML2.

Un navigateur de méta-modèle vous permet d'afficher le méta-modèle utilisé, avec la liste des ses éléments et des liens entre ces éléments. Le navigateur est accessible via le menu principal Window > MetaModel Browser.

Figure 10 - Navigateur de méta-modèle

Le navigateur se compose de deux parties :

La liste des types et énumérations définis dans le méta-modèle, sur la gauche,

La liste des liens du type sélectionné, sur la droite.

Pour un type sélectionné, on affiche :

La liste des types parents,

La liste des sous types,

La liste des liens ( ) vers les autres types du méta-modèle .

Les attributs ( ) : les attributs sont des liens vers des types primitifs.

Le menu contextuel permet :

D'afficher récursivement tous les types parents ou seulement les types parents directs.

D'afficher récursivement tous les sous-types ou seulement les sous-types directs.

D'afficher récursivement tous les liens (définis sur chaque type parent) ou seulement les liens directs (définis sur le type sélectionné).



Edition

Interface Utilisateur du panneau Edition La création, l'édition et la sauvegarde des éléments constitutifs du projet de génération s’effectue dans le panneau Edition.

Figure 11 – Panneau d'édition des scripts



Chargement et sauvegarde d'éléments La chargement et la sauvegarde d'éléments peut se faire à travers les différents menus (menu principal et menus contextuels) ou les icônes de raccourcis.

Figure 12 - Menus de chargement

La sauvegarde des éléments constitutifs du projet et du projet lui même est contextuelle. Pour sauvegarder un élément :

1. Sélectionnez l'élément au travers du navigateur de projet.

2. Lancez la sauvegarde par le bouton

de la barre d'outils. Le même service est fourni par le menu principal File > Save ou File > Save as ….

Remarque : La sauvegarde du projet entraîne la sauvegarde de tous les éléments constitutifs du projet.



Le projet de génération Un projet de génération est un regroupement de tout ce qui est nécessaire à une génération donnée. Un projet de génération peut contenir :

des packages,

des scénarios,

un profil.

Un projet vous permet de sauvegarder tout un environnement de travail, qui pourra être restauré par la suite.

Il y a toujours un projet courant dans MIA-Generation. A l'ouverture de l'application, un projet vide ("Default") est crée par défaut.

Le projet est mis à jour au fur et à mesure que vous ajoutez ou supprimez des éléments de votre environnement de travail.

Attention : Le projet de génération ne conserve pas de référence au modèle utilisé. En effet, le modèle est un paramètre de la génération et n'appartient donc pas directement au projet.

Charger un projet

Le chargement d'un projet permet de restaurer l'environnement de travail. Pour charger un projet quelconque, vous pouvez utiliser :

- les boutons puis de la barre d'outils,

- le menu principal File > Open > Project,

- Le menu contextuel du navigateur de projet Open > Project.

Le menu principal File > Open Recent > Project > … et le menu contextuel du navigateur de projet Open Recent > Project permettent de recharger les derniers projets ouverts.

Sauver un projet

La sauvegarde d'un projet permet de sauver l'environnement de travail.

Pour sauvegarder un projet :

1. Sélectionnez le projet dans le navigateur de projet.

2. Lancez la sauvegarde via le bouton

de la barre d'outils. Le même service est fourni par le menu principal File > Save ou File > Save as … si vous voulez changer la destination de sauvegarde.

Un projet sauvegardé contient les noms de fichiers des différents éléments (packages, scénarios, profil). Les noms de ces fichiers peuvent être sauvegardés en chemin relatif par rapport au projet ou en chemin absolu (voir chapitre Préférences).



Créer un projet

La création d'un projet permet de réinitialiser l'environnement de travail. La création d'un nouveau projet peut se faire par :

- le bouton de la barre d'outils,


- le menu principal File > New > Project.

- le menu contextuel du navigateur de projet New > Project.

Exporter un projet compilé

A chaque script de génération correspond une classe Java compilée, qui permettra ensuite d'évaluer le script avec des objets du modèle. C'est ce qui permet aussi de vérifier la validité des macros et des services.

La première fois que vous chargez un projet dans votre environnement, tous ses scripts sont compilés, ce qui peut prendre un peu de temps.

Pour faciliter l'échange de projets entre utilisateurs, vous pouvez demander à exporter toutes les classes Java compilées qui correspondent à votre projet. Cet export va enregistrer votre projet et créer un nouveau fichier (.dat) qui contiendra tous ces scripts compilés. Ceux-ci seront alors automatiquement importés lors du chargement du projet sur le poste d'un autre architecte, lui évitant une phase de recompilation.

Pour exporter un projet compilé :

1. Sélectionnez le projet dans le navigateur de projets depuis le panneau Edition.

2. Cliquez sur le menu contextuel Export > Compiled project.

Exporter un projet au format Standalone

La fonctionnalité d’exportation de projet dit Standalone permet de packager en en seul fichier l’ensemble des éléments d’un projet (packages, scénarios, profil et scripts compilés) sous un format encodé.

Cette fonctionnalité permet de créer un générateur complet, non modifiable via l’éditeur de scripts. En effet, cette action d’exportation est à sens unique (pas de fonction d'importation dans l'éditeur MIA-Generat ion Architect de ces projets Standalone). Le projet exporté au format Standalone n‘est utilisable qu'avec la version MIA-Generation Developer.

Ceci permet de garantir l'intégrité et la confidentialité des générateurs conçus avec MIA-Generation Architect (développement de générateurs fermés).

Pour sauvegarder un projet au format Standolone :


2. Cliquez sur le menu contextuel Export > Standalone project.

Les projets Standalone sont par défaut sauvés avec l’extension ".prx" (et les projets classiques avec l’extension ".prj").

Regrouper et Exporter les ressources d’un projet dans un dossier

Pour regrouper et exporter les ressources d’un projet (packages, scénarios, profil et scripts) dans un dossier :




2. Cliquez sur le menu contextuel Export > Deployable project > in a directory.

Sélectionnez les ressources que vous souhaiter exporter.

: les ressources que vous ne sélectionnez pas seront partages avec le projet courant.

Figure 13 - Liste des ressources à exporter

Pour renommer le projet

1. cliquez sur l’onglet Options, cochez rename project et entrez le nouveau nom de votre projet.

Figure 14 – Onglet d’Options de ressources à exporter

Regrouper et Exporter les ressources d’un projet dans une archive zip

Pour regrouper et exporter les ressources d’un projet (packages, scénarios, profil et scripts) dans une archive zip:


2. Cliquez sur le menu contextuel Export > Deployable project > in a zip file.



Les packages Un package regroupe un ensemble de scripts qui réalisent une génération. Les packages permettent d'organiser les scripts.

Chaque script, en plus d’être rattaché à un type d’objet, doit être rattaché à un package. Dans un package, il est possible de regrouper des scripts rattachés à des types d’objets différents.

Le but est de pouvoir organiser dans des entités différentes les scripts écrits pour des besoins différents. Cela permet d'organiser les scripts par niveaux : des plus génériques aux plus spécifiques.

GénériqueGénérique

IHMC++IHMC++

JavaJavaC++C++

Modèle métierC++

Modèle métierC++

Modèle métierJava

Modèle métierJava

prérequis

Figure 15 - Exemples de packages

En standard, MIA-Generation fournit un package (non modifiable) appelé "System". Ce package contient un certain nombre de macros et de services de base au méta-modèle utilisé.

Figure 16 - Liste des packages dans le navigateur de projet

Le nom de chaque package est suivi, entre parenthèses, du nombre de scripts définis dans ce package. S'il n'y a aucun script dans le package, le nom apparaît grisé.



Créer et éditer un package

Les scripts doivent être créés dans un package. Or, le seul présent à l'ouverture de MIA-Generation est le package "System" qui ne peut être modifié. Si vous voulez créer vos propres scripts, il faut donc créer un package en utilisant :


- les boutons puis

de la barre d'outils,

- le menu principal File > New > Package.

- le menu contextuel du navigateur de projet New > Project.

Modifier les propriétés d'un package

Vous pouvez modifier les propriétés de ce package : son nom et sa documentation. Pour cela :

1. Sélectionnez un package dans le navigateur de projet.

2. Cliquez sur Properties depuis le menu contextuel de la liste des packages.

Un package est en lecture seule lorsque son fichier associé est en lecture seule. Un package en lecture seule ne peut être modifié, ni aucun de ses scripts.

Figure 17 - Propriétés d'un package



Resynchroniser un package

Dans le cas où vous travaillez en multi-utilisateurs sur le même package, vous pouvez charger les modifications effectuées par une autre personne en utilisant le menu Reload.

Il est possible de resynchroniser ce package en rechargeant la dernière version du fichier.

Pour resynchroniser un package :

1. Sélectionner un package depuis le navigateur de projet

2. Cliquez sur Reload depuis le menu contextuel du navigateur de projet.

Attention

: le rechargement d’un package écrase les modifications que vous avez pu apporter à ce package !

Comparer des packages

Dans le cadre de réorganisation de packages, il est parfois intéressant de comparer un package en mémoire avec un package sauvegardé sur le disque. Pour se faire, MIA-Generation permet de comparer un package en mémoire avec sa dernière version sauvegardé ou avec un autre package sauvegardé sur le disque.

Pour comparer un package avec sa version précédente :


2. Cliquez sur Compare with > Previous version depuis sur le menu contextuel du navigateur de projet.

Pour comparer un package avec un autre package :


2. Cliquez sur Compare with > Other Package … depuis sur le menu contextuel du navigateur de projet.

3. Sélectionner le fichier correspondant au package que vous voulez comparer depuis l'explorateur de fichiers.

Une fenêtre présentant les scripts de chaque package est affichée. Elle présente les scripts organisés par type. Pour chaque script, l’élément de gauche (dont le nom est en gras) représente le script en mémoire et l’élément de droite le script provenant du package que l’on a comparé. Seul le script en mémoire est éditable.

Les scripts peuvent être à l’état :

Modified Le script présente des modifications entre la version en mémoire et la version du package physique comparé.

Added Le script existe seulement en mémoire et est absent du package physique comparé.

Removed Le script n’existe pas mémoire et est seulement présent dans le package physique comparé.



Figure 18 - Comparaison de packages

Les boutons de navigation permettent de parcourir les scripts :

revient à l’élément précédent ou la différence précédente . Cette action est aussi possible via le menu Actions > Previous Difference .

affiche la différence suivante ou le script suivant. Cette action est aussi possible via le menu Actions > Next Difference

L'action LoadRightEdition du menu permet d’importer le script de droite à la place du script de gauche (et de le créer si il s’agit d’un script à l’état Deleted). Cette action est accessible par :

- le bouton de la barre d'outils.

- le menu principal Actions > Load right Edtion.

- l'item Replace with right edtion du menu contextuel de l'éditeur de source.

L’action Save permet de sauvegarder les modifications sur le script de gauche. Cette action est accessible par :



L’action Close (Actions > Close)et le bouton Close permettent de quitter la fenêtre.



Les types La liste des types d'objets contient les types d'objets proposés par le méta-modèle, sur lesquels il est possible de créer des scripts. Elle est visible si au moins un package est sélectionné dans le navigateur de projet.

Le nom de chaque type d'objet est suivi, entre parenthèses, du nombre de scripts définis pour ce type. S'il n'y a aucun script, le nom apparaît grisé.

Cette liste peut être triée de manière alphabétique (menu contextuel View > Alphabetic ou le bouton )

Figure 19 – Types affichés par ordre alphabétique

ou par rapport aux relations d'héritage entre les types d'objets (menu contextuel View > Inheritance ou le

bouton ).

Figure 20 – Types affichés par héritage

Il est possible aussi de ne faire apparaître que les types d'objets pour lesquels il y a au moins un script défini (menu contextuel View > Mask empty types), hors package System.



Figure 21 – Affichage des types ayant au moins un script

Les catégories Les scripts doivent aussi être regroupés au sein de catégories. Il existe, en standard une catégorie nommée "default" dont vous pouvez vous servir. Si vous désirez classer vos scripts de manière plus fine, vous devez créer vos propres catégories. Comme une catégorie est rattachée à un type d'objets, il vous faut obligatoirement sélectionner le type souhaité.

Pour créer une catégorie :

1. Sélectionnez le type souhaité dans la liste des types.

2. Cliquez sur l'item Add … du menu contextuel de la liste des catégories.

Figure 22 - Ajout de catégories



Les scripts Les scripts permettent de décrire comment du texte peut être généré à partir des objets du modèle. MIA-Generation met à votre disposition deux types de scripts de générations :

les modèles textuels de génération ou templates : l’éditeur de templates est de type WYSIWYG (What You See Is What You Get). Ainsi, il suffit de saisir le code qui doit être généré (parsemé d'appels à d'autres scripts) au lieu de le programmer.

Figure 23 - Exemple de Text Template

Les scripts écrits en JAVA™ : les macros et les services. Tout ne pouvant pas être exprimé de manière WYSIWYG,ce sont ces scripts Java qui vont permettre d'obtenir la partie variable du script généré.

Figure 24 - Exemple de Macro

Chaque script est rattaché à un seul type particulier. Il ne pourra donc s'appliquer que sur des objets de ce type, ou d'un sous-type. Pour créer un script, il faut sélectionner au moins un package, le type auquel vous voulez rattacher ce script et la catégorie dans laquelle il sera classé.

Liste des scripts

La liste des scripts contient tous les scripts définis dans les packages sélectionnés, pour le type d'objet sélectionné et dans les catégories sélectionnées. Elle est visible si au moins un package est sélectionné dans le navigateur de projet.

Il est possible de faire apparaître les scripts définis pour les types parents du type sélectionné (menu contextuel View >Show inherited scripts). Le nom des scripts hérités est alors suivi du nom du type pour lequel le script est défini.



Figure 25 – Affichage des scripts hérités

Propriétés des scripts

Les scripts disposent d'un ensemble de propriétés : certaines sont communes à tous les types de scripts, d'autres sont spécifiques. Pour consulter les propriétés d'un script, vous pouvez utiliser le menu contextuel Properties de la liste de scripts.

Figure 26 - Propriétés d'une macro



Propriétés communes

Le nom

Chaque script possède un nom. Le nom des scripts doivent respecter les contraintes suivantes :

- Il ne doit pas ne pas contenir d'espaces, de virgules, de points, de guillemets, d'apostrophes et de parenthèses ouvrantes ou fermantes.

- Il ne doit pas être une valeur numérique entière (ex : 12).

- Les valeurs "true", "false" et "null" sont interdites.

Le type

Le type d'un script est l'élément du méta-modèle sur lesquel il est défini.

Le package

Un script est défini dans un package.

La catégorie

Un script est défini dans une catégorie.

La date de création

La date de création du script est sauvegardée et peut être utilisée comme critère de recherche.

La date de dernière modification

La dernière date de modification du script est sauvegardée et peut être utilisée comme critère de recherche.

L'attribut "Lecture seule

Un script est en lecture seule si le fichier correspondant à son package est en lecture seule. Un script en lecture seule ne pourra pas être modifié.

La documentation

On peut associer un commentaire à chaque script.

Propriétés spécifiques templates, macros et services

L'attribut "Evaluation simple"

Cette propriété permet de spécifier que le script ne doit être évalué qu'une seule fois pour un objet du modèle donné. Le résultat de l'évaluation est alors conservé en mémoire, et directement restitué aux appels suivants. Si par exemple un service effectue un traitement compliqué et coûteux en temps d'exécution, et qu'il est appelé plusieurs fois au cours d'une génération, il peut être utile d'indiquer qu'il ne doit être évalué qu'une seule fois.

Propriétés spécifiques aux macros et services

Le type de retour

Chaque script doit avoir un type de retour. Le type de retour des macros est modifiable, il est fixe pour tous les autres types de scripts.



Pour les scripts de type "Template" au sens large - c'est-à-dire les templates, les file templates, les tags de code utilisateur, la propriété filename des file templates – le type de retour est toujours java.lang.String.

Pour les scripts de type "Macro", le type de retour déclaré est modifiable mais doit être une instance java.lang.Object.

Par défaut, le type de retour des macros est Object mais on peut définir explicitement le type de retour pour des raisons de lisibilité et pour bénéficier d'un typage fort à la compilation.

A la spécification du type de retour, une boîte de dialogue guide l'utilisateur dans la saisie du type. Le type de retour peut être tout type d'objet Java. Des raccourcis Void, Object, Primitive (String, Boolean, Integer, Float) et Model (les types du méta-modèle) permettent de ne pas saisir le nom complet du type. Le type de retour Void est le seul qui autorise l'utilisateur a ne pas mettre de clause return dans son script.

Figure 27 - Spécification du type de retour d'une macro

Le type de retour déclaré d'un service est java.lang.Object et est non modifiable. Dans la pratique, le type réel peut être de plusieurs sortes : un objet du modèle, un tableau d'objets (type java = java.lang.Object[]), une collection d'objets (type java = java.util.Collection) ou une suite d'objets (type java = java.util.Iterator).



Les paramètres

Les macros, templates et services peuvent accepter des paramètres. La saisie des paramètres est accessible à la création du script ou ensuite par ses propriétés. Les principales caractéristiques des scripts avec paramètres sont :

Le nombre de paramètres est quelconque.

Un paramètre est nommé et typé.

Un paramètre ne peut être un type primitif (int, boolean, etc.) : on ne passe que des objets (classes Integer, Boolean, etc.).

Le nom de chaque paramètre doit être un identifiant Java™ valide.

Un script est identifié par son nom et le nombre de ses paramètres.

Il est ainsi possible de définir deux scripts portant le même nom, sous réserve que leur nombre de paramètres soit différent.

Un script ne peut déclarer deux paramètres portant le même nom.

La syntaxe d'appel des paramètres dans les templates et les scripts Java™ est détaillée dans le chapitre "APIs et Notions Avancées/Appel de scripts avec paramètres".

Les paramètres sont donc obligatoirement des objets (instances du type java.lang.Object ou d'un sous-type). A la création du paramètre, une boîte de dialogue guide l'utilisateur dans la saisie du type. Le paramètre peut être tout type d'objet Java. Des raccourcis Object, Primitive (String, Boolean, Integer, Float) et Model (les types du méta-modèle courant) permettent de ne pas saisir le nom complet du type.

Figure 28 - Boîte de dialogue d'ajout de paramètre



Propriétés spécifiques aux services

Type des objets renvoyés par le service

MIA-Generation ne déduit pas automatiquement le type des objets renvoyés. Il faut donc déclarer, au moment de la création du service, quel type d'objets du modèle il renvoie dans l'attribut Returned Objects Type. Même si le service renvoie une collection d'instances de Attribute, le type des objets renvoyés sera Attribute.

Si un service renvoie plusieurs objets (contenus par exemple dans une Collection), le type spécifié doit être une superclasse commune à chacun (s’ils sont tous de la même classe, cela peut-être cette classe). Le type commun est le type "racine" MIAObject.

Figure 29 - Type des objets renvoyés par un service



Créer et éditer un Text Template

Un template est un texte qui décrit de manière visuelle, la façon dont le code doit être généré pour un type d'objet du modèle.

Le texte d’un template est constitué :

d’éléments textuels qui seront reproduits tels quels dans le texte généré.

de noms de scripts dont le résultat, au moment de l'évaluation, sera inséré dans le texte généré.

Appel de scripts depuis un template

Pour distinguer les noms de scripts, ceux-ci sont encadrés par des caractères spéciaux ([[ et ]] par défaut), qui peuvent être modifiés en fonction des besoins de génération (voir le chapitre Préférences).

Exemple de template :

Nom : <nom>Attributs : <attributs>Name: [[name]]

Attributes: [[attributes]]

Adresse________numerorueville

Address________numberstreetcity

Personne________nomprenom

Person________surnamefirst name

Nom : AdresseAttributs : numero rue villeNom: Address

Attributes: number street city

Nom : PersonneAttributs : nom prenomName: Person

Attributes: surname first name

Templaterattaché

Class

Objetsdu modèle

Classde type

Textesgénérés

au type

Figure 30 - Génération d’une description textuelle des objets de type Class du modèle



Pour créer un Text Template :

1. Sélectionner un package et un type sur lesquels vous voulez créer le script 2. Cliquez sur le bouton sur la barre d'outils. Le même service est fourni par le menu contextuel

de la liste de scripts New > Text Template. 3. Lorsque vous créez un Text template, on vous demande de saisir son nom et éventuellement

des paramètres. Une fois le nom saisi, le nouveau script est créé avec un texte par défaut (ce texte par défaut est paramétrable, voir le chapitre Préférences).

Ce texte peut être modifié puis enregistré via le menu contextuel Save text dans la zone de saisie du texte.

Exemple :

Figure 31 - Texte d'un Text template



Créer et éditer un File Template

Il est possible de spécifier le nom du fichier dans lequel le résultat d'un template doit être sauvegardé. Pour ce faire, il faut en faire un File Template. C'est un template auquel est systématiquement rattaché un autre template :

Le nom de fichier (Filename). Une fois évalué, ce template donne le nom du fichier dans lequel le texte du File Template sera sauvé.

Pour créer un File Template :

1. Sélectionner un package et un type sur lesquels vous voulez créer le script 2. Cliquez sur le bouton de la barre d'outils. Le même service est fourni par le menu contextuel de la

liste de scripts New > File Template. 3. Lorsque vous créez un File template, on vous demande de saisir son nom. Une fois le nom saisi, le

nouveau script est créé avec par défaut un texte, un nom de fichier (Filename). Ces textes par défaut sont paramétrables (voir le chapitre Préférences). Chacun de ces textes est un modèle de génération (template). Ils peuvent être modifiés puis enregistrés via le menu contextuel Save text dans la zone de saisie du texte.

Exemples :

Figure 32 - Texte d'un File Template



Figure 33 - Texte du nom de fichier associé à un File Template

Remarque

: Le template Filename qui sert de nom de fichier ou de balise d'insertion n'a pas d'existence

propre en dehors du File template auquel il est rattaché. Il ne peut donc pas être partagé par plusieurs File templates, et la suppression du File template auquel il est rattaché entraîne automatiquement sa suppression.



Créer et éditer des délimiteurs de code utilisateurs

Il est possible de délimiter dans un Template une zone de texte qui pourra être modifiée à la main dans le fichier généré, et qui ne devra pas être écrasée lors d’une future génération. Pour ce faire, il faut utiliser les scripts BeginTag et EndTag qui vous permettent d’encadrer la zone à préserver. Ces balises (qui sont créées en sélectionnant le menu ‘Add tags’) sont elles même des templates, elles apparaissent sous le Template courant.

Exemple :

Figure 34 – Text Template avec du code à préserver



Il existe donc deux marqueurs pour le code utilisateur :

La balise de début de code préservé (BeginTag). Une fois évalué, ce template donne la chaîne de caractères qui marque le début de la partie à préserver dans le fichier.

La balise de fin d'insertion (EndTag). Une fois évalué, ce template donne la chaîne de caractères qui marque la fin de la partie à préserver dans le fichier.

Figure 35 – Template de la balise de début

Lors de la génération, si le fichier n’existe pas, le code est généré avec les balises et, entre les balises, le texte qui est défini dans le script entre les appels à BeginTag et EndTag. Par contre, si le fichier existe, le script BeginTag est évalué et si la balise est présente dans le fichier, le texte qui se trouve entre les deux balises du fichier est récupéré et est replacé entre les deux balises générées.

Le résultat de l'évaluation d'un BeginTag et d'un EndTag doit être unique dans une génération : vous ne pouvez pas par exemple générer deux fois une balise "//Start of user code" dans le même fichier.

Il n'y a pas de restriction concernant les BeginTag et EndTag :

- ils peuvent être positionnés sur une même ligne,

- ils peuvent contenir des sauts de ligne,

- un BeginTag peut être précédé de code généré sur sa ligne, tout comme un EndTag peut être suivi de code généré sur sa ligne,

- etc…



Exemples :

Figure 36 : Exemple d'utilisation des balises (1)

Figure 37 : Exemple d'utilisation des balises (2)

Cas particulier du File Template

Un File Template peut éventuellement n'utiliser qu'un BeginTag ou un EndTag.



BeginTag seul : tout le code compris entre ce BeginTag et la fin du fichier est considéré comme code utilisateur.

EndTag seul : tout le code compris entre le début du fichier et ce EndTag est considéré comme code utilisateur.



Créer et éditer une précondition

Un template peut déclarer une précondition. Une précondition est un script Java™ qui renvoie un objet Boolean.

Cette précondition est évaluée avant le template auquel elle est associée. Le template ne sera évalué que si précondition renvoie vrai, c'est à dire Boolean.TRUE.

Attention

: les macros Java™ renvoient des objets et non pas des types simples. C'est pourquoi une

précondition doit renvoyer une instance de java.lang.Boolean et non pas directement true ou false.

Figure 38 – Précondition d'un Text Template



Créer et éditer une Macro

Une macro est une partie de code, écrite en Java™, qui est évaluée pour un objet du modèle.

Si une macro sert à produire un résultat, c'est-à-dire pour tous les types de retour autre que void, elle doit renvoyer une valeur. C'est pourquoi, l'utilisation du mot-clé return est obligatoire dans ce cas. En dehors de cette contrainte, vous pouvez utiliser tout ce que vous autorise la syntaxe java dans le corps d'une méthode (déclaration de variables, itérations, tests, …).

Exemples de macros

:

return current.getNom();return current.getName();

Adresse________numeroruevillecodePostal

Address________numberstreetcityZIP code



AdresseAddressPersonnePersonTextesgénérés

Macrorattaché

Class

Objetsdu modèle

Classde type

au type

Figure 39 - Macro renvoyant le nom d’une classe

return current.apply("attributes","nom",", ");return current.apply("attributes","name",", ");

Adresse________numeroruevillecodePostal

Address________numberstreetcityZIP code



numero, rue, ville, codePostalnumber, street, city, ZIP codenom, prenomsurname, first name

Macrorattachée

Class

Textesgénérés

Objetsdu modèle

Classde type

au type

Figure 40 - Macro renvoyant la liste des attributs d’une classe



Pour créer une Macro :

1. Sélectionner un package et un type sur lesquels vous voulez créer le script 2. Cliquez sur le bouton de la barre d'outils. Le même service est fourni par le menu contextuel de la liste

de scripts New > Macro. 3. Lorsque vous créez une Macro, on vous demande de saisir son nom et éventuellement des paramètres.

Une fois le nom saisi, le nouveau script est créé avec un texte par défaut (ce texte par défaut est paramétrable, voir le chapitre Préférences). Ce texte peut être modifié puis enregistré via le menu contextuel Save text dans la zone de saisie du texte. Au moment de l'enregistrement le texte, écrit en Java, est compilé. S'il n'est pas correct, un message d'erreur apparaît pour vous indiquer la nature du problème.

Exemple :

Figure 41 - Texte d'une macro



Créer et éditer un Service

Les services sont des macros particulières qui permettent de renvoyer des objets du modèle.

Par exemple, vous pouvez écrire des services pour :

récupérer toutes les classes abstraites d’un modèle

récupérer tous les attributs persistants d’une classe

etc …

Type de retour d'un service

Le type déclaré de retour d'un service est java.lang.Object et est non modifiable. Dans la pratique, le type réel peut être de plusieurs sortes :

un objet du modèle,

un tableau d'objets (type java = java.lang.Object[]),

une collection d'objets (type java = java.util.Collection),

une suite d'objets (type java = java.util.Iterator),

Type des objets renvoyés par le service

MIA-Generation ne déduit pas automatiquement le type des objets renvoyés. Il faut donc déclarer, au moment de la création du service, quel type d'objets du modèle il renvoie dans l'attribut Return Objects Type. Même si le service renvoie une collection d'instances de Attribute, le type des objets renvoyés sera Attribute.

Si un service renvoie plusieurs objets (contenus par exemple dans une Collection), le type spécifié doit être une superclasse commune à chacun (s’ils sont tous de la même classe, cela peut-être cette classe). Le type commun est le type "racine" MIAObject.

Pour créer une Service :

1. Sélectionner un package et un type sur lesquels vous voulez créer le script

2. Cliquez sur le bouton

de la barre d'outils. Le même service est fourni par le menu contextuel de la liste de scripts New > Service.

3. Lorsque vous créez un Service, on vous demande de saisir son nom, puis de choisir le type de des objets renvoyés parmi les types du méta-modèle de MIA-Generation et éventuellement de saisir des paramètres. Une fois le nom et le type des objets renvoyés saisis, le nouveau script est créé avec un texte par défaut (ce texte par défaut est paramétrable, voir le chapitre Préférences). Ce texte peut être modifié puis enregistré via le menu contextuel Save text dans la zone de saisie du texte.

Exemple :

Figure 42 - Texte d'un service



Fonctionnalités d’édition

Dans l’éditeur de texte réservé à la saisie des scripts, il est possible :

de rechercher une zone de texte particulière.

de remplacer une zone de texte par une autre.

d’imprimer le texte du script.

d’annuler la dernière modification.

Il est aussi possible de demander l'aide à la saisie d'appels de scripts. En tapant les touches "Contrôle+Espace" on peut faire apparaître une fenêtre proposant la liste des scripts qui peuvent être utilisés dans le script.

Dans un template, vous pouvez demander l'aide à la saisie après avoir tapé le délimiteur de début de script ([[ par défaut) :

Figure 43 – Aide à la saisie dans un template

Dans un macro ou un service, vous pouvez demander l'aide à la saisie après avoir tapé un guillemet :

Figure 44 – Aide à la saisie dans une macro



Vous pouvez aussi afficher la liste des APIs disponibles sur les variables current et context en demandant l'aide à la saisie après avoir tapé "current." ou "context.".



Naviguer vers un script

Depuis l’éditeur de scripts il est possible de naviguer directement vers un script appelé par le script courant. Voici les différentes manières de procéder :

- le menu contextuel de l’editeur de script Go to > « Nom du script cible »

.

Figure 45 – Menu contextuel Go to

-

- utiliser le raccourci F3 en ayant positionné le curseur sur le script appelé

- utiliser le raccourci Ctrl+clic : maintenez le bouton ctrl enfoncé et survolez à l’aide du curseur de la souris le script à naviguer. Celui-ci est souligné lorsqu’il est sélectionné. Cliquez alors avec la souris pour déclencher la navigation

Figure 46 – Sélection d’un script appelé



Figure 47 – Résultat d’une navigation sans ambigüité

Lorsque la cible de la navigation est ambigüe (lorsque le script appelé est défini sur plusieurs types), une fenêtre apparaît et présente alors l’ensemble des scripts du même nom que le script sélectionné.

Figure 48 – Résultats d’une navigation avec ambigüité



Réorganiser des scripts

Déplacer des scripts

Tous les scripts des packages autres que le package System peuvent être déplacés. Lors d'un déplacement, on peut modifier le package, le type de l'objet auquel est rattaché le script, la catégorie et même le nom de l'objet (pour un simple renommage utiliser plutôt le menu contextuel Rename…). Cette action est disponible via le menu contextuel de la liste de scripts Refactor > Move ….

Figure 49 - Boîte de dialogue de déplacement de scripts

Copier des scripts

Tous les scripts peuvent être copiés. La copie peut s'effectuer dans un autre package, un autre type d'objet, et une autre catégorie. Il est possible aussi de renommer les scripts au moment de la copie. Cette action est disponible via le menu contextuel de la liste de scripts Refactor > Copy ….

Figure 50 - Boîte de dialogue de copie de scripts

Sur un package, une fonctionnalité Move all Scripts… permet de déplacer l’ensemble des scripts du package.



Tester unitairement les scripts

Il est possible de tester individuellement les scripts sans paramètre en utilisant l'item Generate… du menu contextuel de la liste des scripts ou le bouton de la barre d'outils depuis le panneau Edition.

Figure 51 - Test d'un script depuis le panneau Edition

La première fois, une génération unitaire nommée <Nom du script – Type> est créée dans le panneau Generation et vous n'avez plus qu'à sélectionner les objets auxquels vous voulez appliquer le script. Par la suite, si vous cliquez à nouveau sur l'item Generate…, la génération unitaire associée au script sera directement lancée.



Figure 52 - Exemple de génération unitaire

Ce mécanisme est particulièrement utile pour tester vos scripts en phase de développement. Pour une description complète du mécanisme de génération unitaire, voir le chapitre Génération unitaire.



Gérer les conflits de chargement

Une fenêtre présentant les différents conflits est affichée. Elle présente les scripts organisés par type. Pour chaque conflit, l’élément de gauche (dont le nom est en gras) représente le script en mémoire et l’élément de droite le script provenant du package que l’on a voulu charger. De plus, les différences éventuelles sur les deux scripts sont sélectionnées.

Figure 53 – Conflits entre scripts

Pour résoudre un conflit, vous pouvez :

supprimer un des script (à l’aide des boutons "Delete"

pour le script en mémoire ou "Ignore"

pour le script provenant du package en cours de chargement)

changer la signature de l'un ou des deux scripts

changer le type sur lequel le script est défini.

Les boutons de navigation permettent de parcourir les scripts :

revient à l’élément précédent ou la différence précédente . Cette action est aussi possible via le menu Actions / Previous Difference .

affiche la différence suivante ou le script suivant. Cette action est aussi possible via le menu Actions / Next Difference



L'action LoadRightEdition du menu permet de décharger le script de gauche et de charger le script de droite. Cette action est accessible par :



- l'item Replace with right edtion du menu contextuel de l'éditeur de source.

L’action Save permet de sauvegarder les modifications sur le script de gauche. Cette action est accessible par :


- le menu principal Actions > Save.

Si les modifications effectuées sur le script résolvent le conflit, les scripts sont automatiquement supprimés de la vue et ne sont donc plus accessibles par la suite depuis la fenêtre de conflit.

L’action Close (Actions > Close) et le bouton Close permettent de quitter la fenêtre.

Attention : A la fermeture de la fenêtre, les scripts toujours en conflit ne sont pas chargés !



Rechercher un script A tout moment, il est possible de retrouver un script donné. Pour cela il existe plusieurs moyens :

par ses propriétés,

par son statut,

par rapport aux références avec d'autres scripts.

Dans tous les cas le résultat de la recherche est présenté dans une fenêtre de ce type dans laquelle les scripts trouvés sont classés par package et par Type d'objet.

Figure 54 - Résultat d'une recherche de scripts

La sélection d'un script permet de visualiser son texte. Celui-ci peut être modifié et sauvé directement depuis cette fenêtre (menu contextuel Save).

Le bouton Browse vous permet d'accéder directement au script sélectionné.



Recherche à partir de ses propriétés

Cette fonctionnalité de recherche est accessible via le menu contextuel des packages Find Scripts > By properties … depuis le navigateur de projet.

Figure 55 - Menu de recherche de scripts

Une boite de dialogue apparaît dans laquelle vous pouvez saisir les propriétés à rechercher. Les scripts renvoyés seront ceux répondant à tous les critères spécifiés.



Figure 56 - Critères de recherche à partir des propriétés d'un script



Cette boîte de dialogue est composée de plusieurs zones de saisies :

Name : permet de rechercher les scripts par leur nom. Les caractères génériques astérisque (*) et point d'interrogation (?) peuvent être utilisés pour représenter un ou plusieurs caractères véritables dans le nom. Vous pouvez utiliser l'astérisque pour remplacer zéro ou plusieurs caractères. Vous pouvez utiliser le point d'interrogation pour remplacer un seul caractère dans un nom.

Containing text : permet de rechercher les scripts dont le texte source ou la documentation contiennent une certaine chaîne de caractères.

- Source : le texte sera recherché dans le texte source du script

- Documentation : le texte sera recherché dans la documentation du script

- Whole word : recherche les occurrences contenant le mot entier, et non pas des parties de mots

- Match case : recherche les occurrences respectant la casse (majuscules / minuscules)

Attributes : permet de rechercher les scripts à partir de leurs attributs.

- Single evaluation : permet de spécifier l'attribut "Single evaluation" du script recherché.

Script type : permet de filtrer les scripts recherchés suivant leur type. Le type des scripts recherchés devra figurer parmi ceux cochés.

Selected objects : permet de filtrer les scripts recherchés suivant la sélection en cours dans l'éditeur de scripts (on peut ne garder que les scripts définis dans les packages sélectionnés, les catégories sélectionnées, le type sélectionné).

Date : permet de filtrer les scripts recherchés suivant leurs de date de création ou de modification.

- Scripts modified / Scripts created : permet de spécifier si les critères de recherches doivent être appliqués sur la date de création ou de modification des scripts.

- The last n months : permet de rechercher des scripts créés ou modifiés dans les derniers mois, n spécifiant le nombre de mois à prendre en compte.

- The last n days : permet de rechercher des scripts créés ou modifiés dans les derniers jours, n spécifiant le nombre de jours à prendre en compte.

- Between date1 and date2 : permet de rechercher des scripts dont la date de création ou de modification est comprise entre les deux dates spécifiées.

Recherche des scripts en erreur

Cette fonctionnalité de recherche est accessible via le menu contextuel des packages Find Scripts > With Errors … depuis le navigateur de projet. Ce mode de recherche sélectionne tous les scripts en erreur ou en warning.

Recherche des scripts portant le même nom

A partir d'un script on peut retrouver tous les scripts qui ont la même signature par le menu contextuel Declarations of > This script … de la liste des scripts.



Figure 57 - Recherche de références de scripts

Recherche des scripts appelés

A partir d'un script on peut retrouver tous les scripts qui sont appelés par ce script par le menu contextuel Declarations of > Called scripts … de la liste des scripts.

Attention : la recherche s'effectue à partir du nom (si un script référence un script nommé 'a' la recherche renvoie tous les scripts qui s'appellent 'a').

Recherche des scripts appelants

A partir d'un script on peut retrouver tous les scripts qui appellent ce script par le menu contextuel References to > This script … de la liste des scripts.

Attention : la recherche s'effectue à partir du nom (pour un script 'a' la recherche peut renvoyer des scripts qui référencent un autre script nommé aussi 'a').

Recherche des références à un script appelé

A partir d'un script on peut retrouver tous les scripts qui appellent l'un des scripts appelés par le menu contextuel References to > Called Scripts … de la liste des scripts.

Une boite de dialogue apparaît dans laquelle vous pouvez choisir le script appelé pour lequel vous souhaitez connaître les autres scripts qui l'appellent.

Attention : la recherche s'effectue à partir du nom (pour un script référencé dont le nom est 'a', la recherche peut renvoyer des scripts qui référencent un autre script nommé aussi 'a').



Les scénarios Un scénario décrit des enchaînements d'évaluation de scripts.

Un scénario va appeler des services qui vont lui renvoyer des objets du modèle et appliquer sur chacun d’eux des scripts de génération. Dans la pratique un scénario devant permettre de packager un générateur produisant des fichiers, il mettra en relation des services et des file templates.

Comme un scénario peut appeler plusieurs services sur des types d'objets différents et leur appliquer des générations spécifiques, ces enchaînements particuliers sont organisés en description de génération.

Un scénario peut également appeler d'autres scénarios dits sous-scénarios ou scénarios-fils.

Un scénario peut par ailleurs intégrer une transformation d’un modèle en un autre modèle.

La gestion des scénarios s’effectue au moyen de l’éditeur de scénarios, dans le panneau Edition.

Figure 58 – Panneau d'édition des scénarios



Créer un scénario

La création d'un scénario est accessible par :



- le menu principal File > New > Scenario.

- le menu contextuel du navigateur de projet New > Scenario.

Lorsque vous créer un scénario vous devez spécifier son nom et sa visibilité.

Visibilité d'un scénario

Il existe trois types de visibilité pour les scénarios :

La visibilité public est la visibilité par défaut pour les scénarios. Le scénario est dans ce cas visible par l'utilisateur pour toutes les générations standards.

Pour qu'un scénario soit accessible à partir d'un rapport de génération, il doit avoir une visibilité report. La visibilité report permet de spécifier qu'un scénario n'est visible qu'à la suite de la création d'un rapport de génération (voir Rapport de génération).

La visibilité private permet de spécifier qu'un scénario n'est pas directement accessible à l'utilisateur final pour les générations mais doit être inclus dans un autre scénario de visibilité public ou report.

L'utilisation de la visibilité sur les scénarios permet :

- de filtrer les sous-scénarios qui ne devraient pas apparaître à l'utilisateur final

- de distinguer les scénarios accessibles pour les générations initiales des scénarios associés aux rapports de génération.

Sauver un scénario

La sauvegarde du scénario ne sauve que le scénario et ses générations associées. Les scripts référencés doivent être sauvés par l'intermédiaire de leur package.

Pour lancer la sauvegarde d'un scénario :

1. Sélectionnez le scénario dans le navigateur de projet.

2. Lancez la sauvegarde via le bouton

de la barre d'outils. Le même service est fourni par le menu principal File > Save ou File > Save as … si vous voulez changer la destination de sauvegarde.

Charger un scénario

Le chargement du scénario ne charge que le scénario et ses générations associées. Pour charger un scénario quelconque, vous pouvez utiliser :


- le menu principal File > Open > Scenario,

- Le menu contextuel du navigateur de projet Open > Scenario.



Ajouter et supprimer des éléments de scénario

Le panneau Scenario Elements permet d'ajouter, supprimer ou éditer des éléments de scénarios.

Figure 59 - Panneau Scenario Elements

Un scénario peut contenir des descriptions de génération, des transformations de modèle et des appels à d'autres scénarios.

Créer une description de génération

Pour créer les descriptions de génération, vous pouvez :

- utiliser le bouton de la barre d'outils,

- ou cliquer le bouton Add… du panneau des éléments de scénarios et sélectionner le type d'élément

dans la liste.

- ou utiliser le menu contextuel Add ou Insert puis sélectionner le type d'élément

dans la liste.

Créer une transformation

Pour créer les descriptions de transformation, vous pouvez :


- ou cliquer le bouton Add… du panneau des éléments de scénarios et sélectionner le type d'élément

dans la liste.

- ou utiliser le menu contextuel Add ou Insert puis sélectionner le type d'élément dans la liste.

Ajouter un sous-scénario

Un scénario peut contenir des appels à d'autres scénarios. Pour ajouter les descriptions de génération, vous pouvez :


- ou cliquer le bouton Add… du panneau des éléments de scénarios et sélectionner le type d'élément dans la liste.

- ou utiliser le menu contextuel Add ou Insert puis sélectionner le type d'élément dans la liste.



Supprimer un élément d'un scénario

Le bouton Remove permet de supprimer les appels aux sous-scénarios ou les descriptions de génération ou les transformations de modèle.

Editer un élément d'un scénario

Le bouton Edit… permet d'éditer l'élément de scénario courant.



Définir les scripts d'une description de génération

Pour ajouter (ou supprimer) des scripts à une génération, sélectionnez la description de génération de manière à visualiser ses propriétés. La création d'une description de génération se décompose en deux étapes :

1. La sélection des objets sur lesquels va s'appliquer la génération

2. Le choix des scripts que l'on veut appliquer à ces objets

Figure 60 - Définition d'une description de génération

Sélection des objets de génération

Pour spécifier sur quels objets on désire évaluer les scripts, on utilise un service qui va permettre de filtrer les objets du modèle. Pour cela, on procède en deux niveaux de sélection :

Un premier niveau permet de sélectionner un type d'objets désiré (menu déroulant Type). A l'exécution, cela permet de sélectionner toutes les instances de ce type. Une case à cocher with subtypes objects permet d'indiquer qu'on désire récupérer non seulement tous les objets du type spécifié mais aussi de ses sous types.

Un second niveau permet d'affiner la sélection en appliquant un service sur cette première liste d'objets (menu déroulant Service). C'est sur le résultat de ce service que l'on évaluera les scripts. En choisissant le service , aucun filtre ne sera appliqué puisque ce script retourne l'objet courant.



Exemple : Sélections d'objets pour une description de génération

On récupère les objets de type Model (généralement un seul objet par modèle physique chargé) et on sélectionne ensuite toutes les classes entites en appliquant un service allEntities sur l'objet Model récupéré.

Cet exemple récupère toutes les instances dont le type est Classifier ou un de ces type fils. Classifier étant une classe abstraite, on récupère en réalité les instances des sous-types concrets de Classifier : Class, Interface, UseCase, Actor, etc…



Sélection des File Templates

Pour chaque objet, on évalue la liste des files templates. Lors de la création d'une description de génération, on ne peut ajouter que des file templates définis sur le type de retour du service ou un de ses parents.

A l'exécution du scénario, les règles du polymorphisme s'appliquent sur les scripts : c'est le type réel de l'objet qui est pris en compte.

Exemple : Exécution d'une description de génération

On définit sur le type UMLClassifier un file template MyGenerationFile et un text template MyGenerationBody. Ce text template MyGenerationBody fait appel à une macro myDocumentation définie sur UMLModelElement, type parent de UMLClassifier. Le text template MyGenerationBody est redéfini sur deux sous-types de UMLClassifier : UMLInterface et UMLClass.

Le diagramme ci-dessous illustre la hiérarchie des scripts de l'exemple :

Figure 61 - Structure des scripts



On définit pour ces scripts une description de génération permettant de les exécuter : on sélectionne tous les objets de type UMLClassifier et de ses types fils. Sur ces objets, on évalue le file template myGenerationFile.

Figure 62 - Exemple de description de génération

Si on applique la description sur un modèle d'exemple comprenant simplement une classe MyClass, une interface MyInterface et un cas d'utilisation MyUsecase (type UMLUseCase, héritant de UMLClassifier), on obtient trois fichiers dont le contenu respectif est le suivant :

Pour la classe et l'interface, ce sont bien les scripts myGenerationBody redéfinis qui ont été appelés et non pas celui de UMLClassifier. C'est le type réel des objets qui a déterminé le script utilisé.

Pour le cas d'utilisation, on a utilisé le script défini sur son parent UMLClassifier. On constate que pour ce type, le text template myDocumentation défini sur UMLModelElement a été exécuté. En effet, MyUseCase est une sorte de UMLModelElement et une sorte de UMLClassifier.

Définir les paramètres d’une transformation de modèle

Sélectionner une transformation permet de visualiser ses propriétés :



Le projet de transformation

Le scénario de transformation choisi

Les couples de clés/valeurs qui enrichiront le contexte global de transformation.

Figure 63 : Définition d’une transformation

L’indication de la localisation du projet de transformation initialise la liste des scénarii proposés par ce projet. Seuls les scénarii prenant en entrée un seul modèle et générant en sortie un seul modèle basé sur le méta-modèle courant sont autorisés.

Pour chaque scénario, le méta-modèle du modèle résultat est donc indiqué entre parenthèses de façon à faciliter le choix du scénario.

A l’exécution, les couples clé/valeur du contexte global de génération dont la source est autre que ‘System’, sont transmis au transformateur, ainsi que les divers couples ajoutés spécifiquement par l’utilisateur pour ce scénario.



Les profils

Un profil est une façon simple de personnaliser un méta-modèle en ajoutant des types. La façon d'instancier les objets du modèle en fonction d'un profil dépend très fortement du méta-modèle utilisé.

Profil basé sur les stéréotypes

Les stéréotypes sont un bon moyen de paramétrer un modèle, en affinant le type des éléments. Ainsi on pourra distinguer des classes UML suivant leur stéréotype, et effectuer des choix de générations en fonction de celui-ci.

Les stéréotypes définis sur les objets sont récupérés par MIA-Generat ion for UML puisqu'il s'agit d'objets en tant que tels du modèle.

On est alors rapidement amené à écrire des scripts qui sont une succession de tests du stéréotype de l'élément et qui redirige sur différents appels de scripts. En prenant un exemple où des classes seraient stéréotypées "Table" pour modéliser un mapping vers les bases de données, on serait amené à écrire des scripts de la forme suivante :

if (stereotypeName.equals("Table")) ... // traiter le cas des tables

else ... // traiter les classes normales

Dans ce cas il sera plus intéressant d'utiliser un profil. Un profil est un moyen de personnaliser un méta-modèle en lui ajoutant de nouveaux types. C'est un jeu de stéréotypes, chaque stéréotype définissant une nouvelle sous-classe.

Un stéréotype, de manière implicite, est en effet un moyen de définir un nouveau type d'objet. C'est pourquoi, MIA-Generation donne la possibilité de manipuler les objets stéréotypés comme des instances d'un type particulier.

Par exemple, à partir de toutes les classes stéréotypées <<Table>> dans un modèle, MIA-Generation peut en faire non pas des instances de UMLClass mais des instances d'un type Table, sous-classe de UMLClass.

On pourra alors définir un script sur UMLClass, pour y écrire le comportement général d'une classe, et le redéfinir sur Table, pour y définir le texte à générer dans le cas d'une table. On utilise le polymorphisme objet plutôt qu'une imbrication de "if".



Créer et éditer un profil

Pour créer un profil, vous pouvez utiliser :



- le menu principal File > New > Profil,

- Le menu contextuel du navigateur de projet New > Profile.

L'édition d'un profil permet de visualiser la liste alphabétique des types de base du méta-modèle.

Figure 64 – Edition d'un profil

Chaque type ajouté avec le profil apparaît hiérarchiquement sous le type de base du méta-modèle.



On peut demander à ne pas afficher les types du méta-modèle qui ne sont pas étendus par le profil (menu contextuel View >Mask types without profile de la liste des éléments de profil).

Figure 65 – Panneau d'édition du profil

Ajouter un type

L'item Add… du menu contextuel de la liste des éléments du profil permet d'ajouter un sous-type au type sélectionné (que ce soit un type de base du méta-modèle ou un type du profil).

Déplacer un type

L'item Move… du menu contextuel de la liste des éléments du profil permet de changer le type parent du type sélectionné. Cette fonction n'est possible que si :

Le type sélectionné n'est pas un type de base du méta-modèle.

Le modèle chargé dans MIA-Generation ne comporte pas d'objets du type sélectionné.

Les scénarios chargés ne référencent pas le type sélectionné.



Supprimer un type

L'item Remove du menu contextuel de la liste des éléments du profil permet de supprimer un type du profil, ainsi que tous ses sous-types. Cette fonction n'est possible que si :

Le type sélectionné n'est pas un type de base du méta-modèle.

Le modèle chargé ne comporte pas d'objets du type sélectionné ou de ses sous-types.

Les packages chargés n'ont pas de scripts de génération rattachés au type sélectionné ou un de ses sous-types.

Les scénarios chargés ne référencent pas le type sélectionné ou un de ses sous-types.

Chargement de modèles tenant compte du profil

Le chargement des modèles tient automatiquement compte du profil chargé dans MIA-Generation lors de l'instanciation des objets. Vous n'avez jamais à modifier les composants Java d'import de modèles pour cela.

Création de scripts sur des types du profil

Les types définis dans le profil apparaissent dans la panneau des scripts.

Figure 66 – Types du profil dans le panneau de scripts

Vous pouvez alors définir des scripts sur ces types exactement de la même manière que sur les types de base du méta-modèle, en bénéficiant des mêmes fonctionnalités (héritage, polymorphisme, etc.)



Les plugins

Un plugin est une façon simple de personnaliser l'environnement de travail en ajoutant des menus dans les menus contextuels existants. Ces nouveaux menus peuvent par exemple servir à mettre les ressources du projet courant sous gestion de configuration, générer des fichiers d'informations sur les scripts, d'accéder à des outils personnels…

Les actions associées à ces nouveaux menus sont en fait des scripts développés au sein même de MIA-Generat ion Architect . Ces scripts sont indépendants du méta-modèle utilisé puisqu'ils n'ont pas pour vocation de s'intégrer dans un générateur mais plutôt de manipuler les constituants d'un projet. Le contexte global fournit d'ailleurs des APIs permettant d'accéder entre autres à la ressource sélectionnée ou au script sélectionné, etc…

Par défaut, les plugins disponibles sont chargés dans l'environnement au lancement de MIA-Generation. Ils peuvent également être chargés ou déchargés ultérieurement par l'utilisateur. Le fait de charger un plugin insère automatiquement les menus définis par celui-ci dans l'environnement. A l'inverse, le fait de décharger un plugin entraîne le retrait des menus qu'il définit.

Créer un plugin

Pour créer un plugin, vous pouvez utiliser :



- le menu principal File > New > Plugin,

- le menu contextuel du navigateur de projet New > Plugin.

L'écriture d'un plugin est identique à celle d'un package à la différence près qu'il n'y a qu'un seul type disponible : le type racine MIAObject.

Figure 67 : Ecriture d'un plugin

De même que pour un package, le nom de chaque plugin est suivi, entre parenthèses, du nombre de scripts définis dans ce plugin. S'il n'y a aucun script dans le plugin, le nom apparaît grisé.



Administrer les plugins

Pour charger, décharger ou éditer des plugins facilement, vous pouvez utiliser le menu principal Window > Plugins…. Ceci ouvre une boîte de dialogue indiquant les différents plugins chargés dans l'environnement.

V

Figure 68 : Administrer les plugins

Les plugins grisés sont des plugins pré-requis d'autres plugins, et qui ne peuvent pas être déchargés (Cf. Notion de plugin pré-requis). Les plugins apparaissant au 1er niveau sont les plugins chargés explicitement par l'utilisateur, soit via le fichier de configuration "plugins.cfg" soit via le bouton Load new plugin (Cf. Editer ou charger un plugin).

Editer ou charger un plugin

Charger un plugin consiste à insérer les différents menus qu'il définit dans les menus existants de l'environnement.

Editer un plugin consiste à visualiser les scripts qui le composent.

Editer un plugin non chargé provoque son chargement.

Les plugins dont l'emplacement relatif sur le disque est indiqué dans le fichier "<MIA-Generation>\plugins\plugins.cfg" sont chargés au lancement de MIA-Generation.

Exemple : <PLUGINS>

<PLUGIN filename="launcher.plg"/>

<PLUGIN filename="commonPlugin.plg"/> </PLUGINS>

Toutefois, il est possible de charger un plugin ultérieurement en suivant les indications ci-dessous.



Pour éditer ou charger un plugin, vous pouvez utiliser :


- le menu principal File > Open > Plugin,

- le menu contextuel du navigateur de projet Open > Plugin,

- le menu principal Window > Plugins…, sélectionner le plugin chargé, ou utiliser le bouton Load new plugin si le plugin n'est pas encore chargé, puis utiliser le bouton Edit.

Recharger un plugin

Pour recharger un plugin, vous devez utiliser le menu principal Window > Plugins…, puis sélectionner le plugin et utiliser le bouton Reload. Cette action est particulièrement utile pendant la phase de mise au point d'un plugin, notamment lorsqu'il s'agit de positionner les nouveaux menus par rapport à ceux déjà existants.

Décharger un plugin

Pour décharger un plugin, vous devez utiliser le menu principal Window > Plugins…, puis sélectionner le plugin et utiliser le bouton Unload, ou utiliser le bouton Unload all plugins pour décharger tous les plugins.

Remarque

: Le menu principal File > Close, ou le menu contextuel du navigateur de projet Close, permettent de fermer l'édition d'un plugin mais pas de le décharger.

Notion de chemin menant à un menu

Il n'y a actuellement pas d'éditeur au sein de MIA-Generat ion Architect permettant de construire les menus du plugin de façon assistée. Cette action doit être réalisée manuellement.

Après la création de votre plugin et la sauvegarde de ses scripts, vous obtenez un fichier au format XML dont l'extension est ".plg". Ce fichier regroupe les différents scripts nécessaires au fonctionnement du plugin. Il faut y ajouter les indications permettant d'intégrer des menus dans les menus existants. Ces indications reposent sur la notion de "chemin".

Pour intégrer un nouvel élément de menu, celui-ci doit connaître le "chemin unique" menant à son voisin le plus proche. Par défaut, le voisin le plus proche deviendra le prédécesseur du nouveau menu (Cf. Positionner un élément). Pour construire ce chemin, chaque menu contextuel porte un nom qui l'identifie de manière unique. Le chemin menant à un élément de menu sera donc construit de la façon suivante :

'<nom du menu contextuel>.<nom de l'élément de menu>'

Exemple :

nom du menu contextuel : Scripts

nom de l'élément de menu : Rename…

chemin : Scripts.Rename…



Figure 69 : menu 'Scripts.Rename...'

Pour ajouter un élément de menu dans un sous-menu, la construction du chemin repose sur le suffixage du chemin menant au menu parent par le nom du sous élément :

'<nom du menu contextuel>.<nom du sous menu>.<nom de l'élément du sous-menu>'

Exemple :

nom du menu contextuel : Scripts

nom du sous-menu : Refactor

nom de l'élément de menu : Copy…

chemin : Scripts.Refactor.Copy…



Figure 70 : Menu 'Scripts.Refactor.Copy...'

Pour les menus contextuels associés à une liste hiérarchique dont les constituants sont de type différents, le nom sera parfois construit de la façon suivante :

'<nom du menu contextuel>.<type d'élément sélectionné>'

Exemple : dans l'onglet 'Edition' de MIA-Generation Architect, le

nom du menu contextuel : Edition

nom de l'élément sélectionné : Package

nom de l'élément de menu : New

chemin : Edition.Package.New



Figure 71 : Menu 'Edition.Package.New'

La liste exhaustive des noms des menus contextuels personnalisables est donnée en fin de chapitre.

Ajouter un élément de menu dans un menu contextuel existant

Exemple : dans l'onglet 'Edition' de MIA-Generation Architect, on souhaite ajouter l'élément de menu Create launcher dans le menu contextuel accessible lorsqu'un scénario est sélectionné. On souhaite le positionner après l'élément de menu Generate…. Actionner ce menu devra déclencher l'évaluation du script nommé "createLauncher".

Il faut alors ajouter la ligne suivante dans le fichier ".plg" représentant le plugin :

<MENU_ITEM NAME="Create launcher" CLOSER_ITEM_PATH="Edition.Scenario.Generate…" SCRIPT="createLauncher"/>

Le résultat est le suivant :

>

Figure 72 : Ajout d'un élément de menu

Ajouter un séparateur de menu dans un menu contextuel existant

Partant de l'exemple précédent, on souhaite ajouter un séparateur de menu entre le nouveau menu ajouté et son prédécesseur.


<MENU_SEPARATOR CLOSER_ITEM_PATH="Edition.Scenario.Generate…"/>



Le résultat est le suivant :

>

Figure 73 : Ajout d'un séparateur

Remarque

: les séparateurs ne portant pas de nom, ils ne peuvent pas être utilisés en tant que 'plus proche voisin'.

Ajouter un menu dans un menu contextuel existant

Partant de l'exemple précédent, on souhaite positionner après le menu Open recent, un menu Team contenant 2 éléments: Commit et Update.


<MENU NAME="Team" CLOSER_ITEM_PATH="Edition.Scenario.Open recent">

<MENU_ITEM NAME="Commit" SCRIPT="commit"/>

<MENU_ITEM NAME="Update" SCRIPT="update"/> </MENU>

Figure 74 : Ajout d'un menu

Positionner un élément

Par défaut, un élément de menu est ajouté après son voisin le plus proche, c'est-à-dire son prédécesseur.

L'ordre des lignes dans le plugin est donc important lorsqu'un même menu est référencé par plusieurs autres. Les menus du plugin sont insérés dans l'ordre de lecture du plugin, et non dans l'ordre d'écriture.



Exemple :

<MENU_ITEM NAME="Create launcher" CLOSER_ITEM_PATH="Edition.Scenario.Generate…" SCRIPT="createLauncher"/> <MENU_SEPARATOR CLOSER_ITEM_PATH="Edition.Scenario.Generate…"/>

donne :

Figure 75 : Le séparateur, inséré en 2nd, se retrouve avant le menu Create launcher

alors que :

<MENU_SEPARATOR CLOSER_ITEM_PATH="Edition.Scenario.Generate…"/> <MENU_ITEM NAME="Create launcher" CLOSER_ITEM_PATH="Edition.Scenario.Generate…" SCRIPT="createLauncher"/>

donne :

Figure 76 : Le séparateur, inséré en 1er, s'éloigne de son voisin le plus proche

Pour éviter ce genre de désagrément, il est possible d'insérer les éléments de menu avant leur voisin le plus proche (qui devient donc leur successeur), en utilisant l'attribut POSITION et le mot clé before :

<MENU_SEPARATOR CLOSER_ITEM_PATH="Edition.Scenario.Create launcher" POSITION="before"/>

>



Figure 77 : Utilisation di mot-clé 'before'

Notion de plugin pré-requis

L'attribut CLOSER_ITEM_PATH peut référencer tout menu existant ou ajouté par le plugin lui-même ou par un autre plugin. Dans ce dernier cas, le plugin installant le menu référencé devra figurer dans les pré-requis du plugin courant, de la façon suivante :

<PREREQUISITES>

<PREREQUISITE FILENAME="d:\Mia-Generation 4.10.0\Plugins\commonPlugin.plg"/> </PREREQUISITES>

Le chargement d'un plugin entraîne le chargement de ses plugins pré-requis.

Un plugin pré-requis ne peut être déchargé tant qu'un plugin dépendant est chargé. Il apparaît grisé :

Figure 78 : Visualisation des plugins pré-requis

Utiliser les expressions régulières

L'utilisation d'expressions régulières est possible, par exemple pour rendre un menu disponible quelque soit le type d'élément sélectionné :

<MENU NAME="Team" CLOSER_ITEM_PATH="Edition.*.Open recent">

<MENU_ITEM NAME="Commit" SCRIPT="commit"/>

<MENU_ITEM NAME="Update" SCRIPT="update"/> </MENU>



Figure 79 : Ajout d'un sous-menu en utilisant une expression régulière

Liste des menus contextuels actuellement personnalisables

Voici les noms des différents menus contextuels qu'il est possible de personnaliser :

dans l'onglet ''Edition' de Mia-Generation Architect :

- lorsqu'un projet est sélectionné, le menu contextuel 'Edition.Project' est accessible :

Figure 80 : Menu contextuel 'Edition.Project'

- lorsqu'un scénario est sélectionné, le menu contextuel 'Edition.Scenario' est accessible :

Figure 81 : Menu contextuel 'Edition.Scenario'

- lorsqu'un package est sélectionné, le menu contextuel 'Edition.Package' est accessible :



Figure 82 : Menu contextuel 'Edition.Package'

- lorsqu'un profile est sélectionné, le menu contextuel 'Edition.Profile' est accessible :

Figure 83 : Menu contextuel 'Edition.Profile'

- lorsqu'un plugin est sélectionné, le menu contextuel 'Edition.Plugin' est accessible :

Figure 84 : Menu contextuel 'Edition.Plugin'

- lorsque plusieurs packages sont sélectionnés, le menu contextuel 'Edition.Packages' est accessible :



Figure 85 : Menu contextuel 'Edition.Packages'

- lorsque plusieurs éléments constitutifs d'un projet mais de type différents sont sélectionnés, le menu contextuel 'Edition.Project Units' est accessible :

Figure 86 : Menu contextuel 'Edition.Project Units' '

- lorsqu'aucun élément modifiable n'est sélectionné, ou lorsque plusieurs éléments de type différents sont sélectionnés, le menu contextuel 'Edition' est accessible :

Figure 87 : Menu contextuel 'Edition'

Dans la partie 'Scripts' de Mia-Generation Architect :

- lorsqu'aucun script n'est sélectionné, le menu contextuel 'NoScript' est accessible :

Figure 88 : Menu contextuel 'NoScript'

- lorsqu'un ou plusieurs scripts sont sélectionnés, le menu contextuel 'Scripts' est accessible. Son aspect est le suivant :



Figure 89 : Menu contextuel 'Scripts' de base si un ou plusieurs scripts sont sélectionnés

Ce menu possède des éléments ajoutés dynamiquement en fonction des propriétés du script sélectionné. Pour autant, le menu contextuel conserve son nom 'Scripts' sans distinction quant à ces propriétés spécifiques.

lorsqu'un TextTemplate ou un FileTemplate est sélectionné, les éléments suivants sont potentiellement disponibles dans le menu contextuel 'Scripts' :

Figure 90 : Eléments de menu supplémentaires si un TextTemplate ou un FileTemplate est sélectionné

lorsqu'un Service est sélectionné, les éléments suivants sont potentiellement disponibles dans le menu contextuel 'Scripts' :

Figure 91 : Eléments de menu supplémentaires si un Service est sélectionné

- lorsqu'un Filename, une Précondition, un BeginTag ou un EndTag est sélectionné, le menu contextuel 'Scripts.Properties' est accessible :

Figure 92 : Menu contextuel 'Scripts.Property'



Génération

Généralités La génération de code s'effectue dans le panneau Launchers.

Figure 93 - Le panneau de lancement des générations

La génération peut s'effectuer selon deux modes :

Génération par lanceur pour un scénario donné

Génération unitaire : par sélection d'objets et de scripts à appliquer sur ces objets.



Chargement des modèles

Généralités

Les modèles, sur lesquels s'effectue la génération, sont consultables sous l'item Model depuis le navigateur de projet du panneau Generation .

MIA-Generation gère un seul modèle à la fois. Ce modèle est importé depuis un AGL. Le modèle peut être visualisé via un navigateur intégré à MIA-Generation. Ce navigateur permet de parcourir tous les objets du modèle, et sur chacun on peut voir ses propriétés et les objets qui lui sont rattachés.

Figure 94 – Panneau de gestion du modèle



Importer un modèle depuis un AGL

Pour importer un modèle saisi avec un autre outil, vous pouvez utiliser :


- le menu principal File > Open > Model,

- le menu contextuel du navigateur de projet Open > Model.

Le menu principal File > Open Recent > Model > … et le menu contextuel du navigateur de projet Open Recent > Model permettent de recharger les derniers modèles ouverts.

MIA-Generation est capable d'importer des modèles de plusieurs outils. Vous devez donc choisir le type de modèle à importer :

Figure 95 – Choix du format d'import

Lorsque vous avez choisi le format, si ce format se base sur le chargement d'un fichier, vous pouvez sélectionner le fichier à analyser. Le modèle importé remplace alors le modèle en cours dans MIA-Generation.

Si des problèmes d'import sont détectés, ils sont affichés dans la console d'import, accessible via le menu Window > Console > Import.

Synchroniser le modèle

Si le modèle est modifié extérieurement, pendant la période où il est chargé dans MIA-Generation, il est

possible de forcer la synchronisation en rechargeant le modèle avec le bouton de la barre d'outils.



Consulter un modèle

La navigateur de modèle se découpe en quatre zone :

Une zone de titre, avec le nom du méta-modèle suivi du nom du modèle

La liste des types du méta-modèle

Un arbre des instances du type sélectionné

Un liste d'attributs de l'instance sélectionnée

Figure 96 - Navigateur de modèle

La liste des types affiche les types définis dans le méta-modèle référencé. On affiche entre parenthèses le nombre d'instances de chaque type.

L'arbre des instances affiche la liste des instances du type sélectionné. On peut naviguer au travers des liens de chaque instance vers les autres objets du modèle. Pour chaque lien, on affiche entre parenthèses le nombre d'objets rattachés. On affiche au-dessus de l'arbre le nom de l'instance sélectionnée, suivi du nom de son type.

La liste des attributs affiche les attributs de l'instance sélectionnée. Si c'est un lien qui est sélectionné et que seul un objet est rattaché via ce lien, on affiche alors les attributs de l'objet rattaché.



Génération par scénario grâce à un lanceur Les scénarios permettent de packager une génération en associant des services prédéfinis à différents file templates.

La génération par scénario consiste à choisir un scénario de génération, puis à lancer la génération en

utilisant le bouton de la barre d'outils ou le menu contextuel Generate….

Figure 97 – Sélection d'un scénario

Remarque : Seuls les scénarios publics et valides peuvent être lancés depuis cette interface.

Ceci aura pour effet de créer un lanceur dans le panneau Launchers s'il n'en existe pas déjà un pour le scénario sélectionné, et de lancer automatiquement la génération sur le modèle courant.



Figure 98: Lanceur créé à partir d'un scénario

Un lanceur référence principalement un projet de génération, un scénario et un modèle, et positionne un certain nombre d'options de génération. Il peut également décrire les transformations de modèle éventuellement portées par le scénario sélectionné, et permet de plus d'insérer des entrées dans le contexte global de génération.

Un lanceur peut être sauvegardé dans un fichier d'extension '.lnc', et ainsi être réutilisé. Par défaut, le répertoire contenant tous les lanceurs chargés au démarrage de Mia-Generation est '<Mia-Generation>\launchers'.



Générations unitaires Une génération unitaire se décompose en trois étapes. Il faut d'abord sélectionner les scripts que vous voulez tester. Ensuite il faut sélectionner les objets sur lesquels la génération va s'appliquer. Il ne reste alors plus qu'à lancer la génération.

Figure 99 – Sélection des objets source et des scripts

Tous les types de scripts peuvent être testés unitairement : templates, file templates, macros et services. Ce mécanisme de génération unitaire est particulièrement utile pour tester vos scripts en phase de développement sans passer par la création d'un file template. La seule restriction est que les scripts à tester ne déclarent pas de paramètres.

Créer une génération unitaire

Pour créer une génération unitaire, vous pouvez utiliser :

- le menu contextuel New> Generation Units dans le navigateur Launchers et ensuite créer une génération unitaire de toute pièce en utilisant les fonctions d'ajout/suppression de scripts et d'objets,

- l'item Generate… du menu contextuel de la liste des scripts ou le bouton

de la barre d'outils depuis le panneau Edition. La première fois, une génération unitaire nommée <Nom du script – Type> est créée et vous n'avez plus qu'à sélectionner les objets auxquels vous voulez appliquer le



script. Par la suite, si vous cliquez à nouveau sur l'item Generate… du menu contextuel de la liste des scripts, la génération unitaire associée au script sera directement lancée.

Sélection des scripts

Pour sélectionner un script :

1. Sélectionnez le type avec le menu déroulant Type : ce type détermine sur quel élément du méta-modèle vous voulez sélectionner puis tester des scripts.

2. Cliquez sur le bouton Add… de la liste Scripts, une fenêtre dédiée vous permet de sélectionner les scripts :

Figure 100 - Sélection des scripts

Dans la liste Scripts apparaissent tous les scripts définis sur le type sélectionné (ou sur ses parents).

Sélection des objets source

Pour sélectionner un objet :

1. Sélectionnez le type avec le menu déroulant Type : ce type détermine sur quel élément du méta-modèle vous voulez sélectionner puis tester des scripts.



2. Cliquez sur le bouton Add… de la liste Objects, une fenêtre dédiée vous permet de sélectionner les objets :

Figure 101 – Sélection des objets

Le titre de la fenêtre de sélection rappelle le type des instances requises pour la génération : ce type est celui sélectionné dans le menu déroulant de la génération unitaire.

Dans le menu déroulant Type of objects, choisissez le type des objets que vous souhaitez sélectionner. Tous les objets du type choisi apparaissent alors dans la liste Available objects. Si vous souhaitez aussi voir apparaître les objets des sous-types cochez with subtypes objects.

Sélectionnez ensuite un service parmi ceux disponibles pour le type choisi. Appliqué sur les objets sélectionnés dans la liste Available objects, le service permet éventuellement de déduire d'autres objets. Par défaut, c'est le service current (disponible en standard) qui est sélectionné, ce qui permet de déduire exactement les mêmes objets que ceux sélectionnés dans Available objects.

Ce mécanisme est très utile lorsque vous souhaitez lancer la génération sur un sous-ensemble précis d'objets. Plutôt que de les sélectionner à la main, vous pouvez ainsi écrire un service qui les calcule automatiquement. De cette façon, par exemple, vous pouvez très facilement (et sans risque d'oubli) lancer la génération sur toutes les classes persistantes d'un modèle, ou sur toutes les sous-classes d'une classe particulière.

Le service choisi est automatiquement appliqué sur chacun des objets sélectionnés dans Available objects, et les objets déduits sont placés dans la liste Deducted objects (si le même objet est déduit plusieurs fois, il n'apparaîtra qu'une seule fois dans cette liste).

C'est parmi ces objets déduits que vous sélectionnez définitivement les objets sur lesquels vous souhaitez lancer la génération. Pour cela, utilisez les flèches qui vous permettent d'ajouter ou d'enlever des objets.

Lorsque votre choix est fait, cliquez sur le bouton Ok pour mettre à jour la liste des objets dans la fenêtre de génération (les objets sélectionnés remplacent les précédents).

Lorsque vous avez sélectionné les objets et les scripts, il ne vous reste plus qu'à lancer la génération à

l'aide du bouton Generate ou du bouton de la barre d'outils.



Remarque

: Sur chaque liste d'objets, le menu contextuel Select all, permet de sélectionner tous les

objets de la liste.

Options de génération

Options générales de génération

Mode de génération

L'utilisateur a le choix entre deux modes de génération : à l'écran ou dans un fichier.

Génération à l'écran (Generate on SCREEN)

Aucun fichier n'est généré. Les noms des fichiers virtuellement générés apparaissent dans la liste Results. En sélectionnant un nom de fichier, le contenu généré apparaît dans la zone de texte Generated text.

Figure 102 – Génération à l'écran

Génération dans des fichiers (Generate into FILES)

Pour chaque script, le résultat de la génération est sauvegardé dans un fichier dont le nom est déduit à partir du nom de fichier (Filename) associé au script. Si le fichier n'est pas présent sur le disque, il est créé. Sinon, il est remplacé par le résultat de la génération. S'il existe des parties de code balisées, elles sont récupérées et réinsérées dans le fichier.

Selon que la génération crée un nouveau fichier ou mette à jour un fichier déjà existant, le nom du fichier est précédé par un icône différent:

Fichier créé

Fichier modifié



Fichier non modifié

Répertoire de génération par défaut

L'utilisateur peut choisir le chemin de génération par défaut des fichiers. Si les noms de fichiers calculés pour les fichiers (propriété Filename des file templates) ne sont pas absolus, ils sont alors résolus avec ce répertoire.

Source & Target

Par défaut, ce chemin de génération représente aussi l'emplacement des fichiers à partir desquels le code manuel sera extrait. Mais il est possible de distinguer le répertoire de génération cible qui va accueillir les fichiers générés, du répertoire source contenant le code manuel, comme le montre la Figure 103 :

Figure 103 : Distinction des répertoires source et cible

Attention !

Toute modification manuelle apportée dans le répertoire cible sera perdue. Cette option est donc à utiliser avec précaution et dans des cas précis où l'on ne souhaite pas écraser les fichiers de référence à chaque génération.

Traces

Une option de trace (Generate trace) est également disponible depuis l'onglet General. Notez que l'utilisation des traces à un coût en temps de génération et en mémoire.

Cette option permet de mémoriser tous les appels de scripts déclenchés durant la génération. Une fois la génération terminée, ces appels sont consultables dans le panel dédié aux traces (chapitre Traces).

Options du contexte

Nettoyage du contexte (Clear context before generating)

Cette option permet de réinitialiser la variable context. Cette action a pour conséquence de supprimer toutes les entrées de ce dictionnaire, sauf celles qui correspondent à des paramètres lus en ligne de commande (voir chapitre Ligne de commande).

Fermeture automatique de la console de génération (Close console when generation is completed)

Cette option permet de spécifier si la console de génération doit être fermé automatiquement ou non à la fin de la génération.



Figure 104 : options du contexte de génération



Options des fichiers

Figure 105 - Options de génération des fichiers

Saut de ligne des fichiers générés (Line Separator)

Par défaut les sauts de lignes des fichiers générés sont ceux du système d'exploitation sur lequel s'exécute MIA-Generation. Mais vous pouvez demander à générer des sauts de lignes pour une plate-forme donnée. Ainsi il est possible de générer depuis une plate-forme Windows des fichiers utilisables sous la plate-forme Linux.

Minimiser l'écriture des fichiers (Overwrite files only when modified)

Lorsque cette option est activée, seuls les nouveaux fichiers et les fichiers modifiés sont sauvegardés. De cette façon, tous les fichiers qui n'ont pas été modifiés par la génération ne sont pas touchés.

Générer tous les résultats avant l'écriture des fichiers (Generate all files before writing)

Lorsque cette option est activée, tous les résultats sont évalués avant d'être sauvegardés dans des fichiers. Dans le cas contraire, chaque résultat est sauvegardé dans un fichier avant de passer au suivant.

Cette option permet, si elle est cochée, de n'avoir écrit aucun fichier si une erreur de génération intervient au cours de la génération et que l'on demande à arrêter l'évaluation. Elle permet, si elle est décochée, de libérer de la mémoire car chaque fichier est écrit après son évaluation et non pas stocké en mémoire : cette option est particulièrement utile en cas de génération de très gros fichiers (plusieurs Mo).

Options de rapport de génération

Un rapport de génération peut être calculé à l'issue de la génération. L'onglet Report permet de saisir les paramètres de ce rapport.



Figure 106 - Options de rapport de génération

Le rapport contient toutes les informations relatives à la génération courante :

Le label de la génération courante (champ New report label)

Le rapport de référence (champ Reference report)

Le modèle et son label (champ Model label)

Les éléments du générateur (packages, scénarios et profil) et leur label (champ Generator label)

Les fichiers générés et leurs statuts associés (New, Modified, Unmodifed, Manually modified, Removed …)

Une case à cocher Select report when generation is completed permet de sélectionner le rapport dans le navigateur après la génération. Si cette case n'est pas cochée, c'est le premier résultat de génération qui est sélectionné.



Paramètres de transformation

Pour lancer une transformation, certaines informations sont obligatoires. L’onglet Transformation permet d’indiquer ces informations.

Figure 107 : Paramètres de transformation

Pour chaque transformation, il faut indiquer :

le format du modèle en entrée (champ Format),

le chemin d’accès au modèle à transformer (champ File), ou bien le modèle courant si un modèle est chargé (radio bouton Current Model),

l’écrivain nécessaire à l’écriture du modèle transformé (champ Writer),

le lecteur permettant de recharger le modèle transformé (champ Reader).

Un menu contextuel Change directory permet de modifier l’emplacement du projet de transformation. Un double-click sur la ligne sélectionnée le permet également.

Option

Rechargement automatique du modèle après la génération (Reload model when generation is completed)

Cette option permet de recharger le modèle initial à la fin de la génération. Cette option est particulièrement utile lorsqu’un scénario de génération intègre une transformation de modèle car après chaque transformation, le modèle résultant devient le modèle courant.



Consulter le résultat d'une génération

Trier les résultats de génération

Dès qu'une génération est terminée, tous les fichiers générés apparaissent dans la liste Results. Les résultats de génération peuvent être affichés de différentes façons grâce au menu contextuel View de liste Results.

Figure 108 - Menu contextuel de la liste des résultats de génération

L'item View > Sort permet de trier par ordre alphabétique les fichiers générés.

Les options View > File Name, View > Relative path, View > Full path permettent respectivement de n'afficher que le nom du fichier, son chemin relatif par rapport au répertoire de génération par défaut et le chemin complet.

L'item View > Failed preconditions permet d'afficher dans la liste des évaluations qui n'ont pas produit de fichier à cause de préconditions fausses.

Il est alors possible de consulter le contenu de chaque fichier généré. Pour cela, il suffit de sélectionner le fichier, et son contenu apparaît dans la zone de texte situé à droite de la liste.

Accéder à la trace de génération et au script d'origine

Les menu contextuels Browse > Trace step et Browse > Definition Script permettent respectivement d'accéder à la trace associé au fichier si elle existe et au script évalué.

Sauvegarder le texte généré dans un autre fichier

Il est possible de sauvegarder le texte généré dans un autre fichier (menu contextuel Save et Save as … de la liste Results).

Regénérer individuellement un fichier

Il est possible de regénérer un fichier individuellement (menu contextuel Regenerate … de la liste Results).

Effectuer une recherche dans le texte généré

Il est possible de rechercher du texte dans le contenu d'un fichier généré (menu contextuel Find/Replace… de la zone de texte Generated text).

Imprimer le texte généré

Le texte généré peut être imprimé directement (menu contextuel Print… de la zone de texte Generated text).



Détection des erreurs de génération En cas d'erreur de génération, le nom du fichier est préfixé d'une croix rouge, et si on sélectionne ce fichier, c'est le texte de l'erreur qui apparaît dans la zone de texte.

Figure 109 – Résultat d'une erreur de génération

Le texte de l'erreur décrit la pile d'exécution et le texte précis de l'erreur.

Pour chaque niveau de la pile d'exécution sont indiqués le script dans lequel s'est produit l'erreur, et sur quel objet (nom et type) ce script a été évalué.

En phase de mise au point, si l'erreur est due à un problème dans un script, celui-ci peut être corrigé et le fichier peut être regénéré individuellement (menu contextuel Regenerate).

Résolution des erreurs de génération

Pour résoudre une erreur de génération, vous pouvez vous appuyer sur le message de l'erreur mais également utiliser le mécanisme de traces.

Les traces de génération vont vous permettre d'isoler le script en erreur et surtout de voir le "chemin" ou l'arbre de génération qui a précédé cette erreur. Depuis la trace, vous allez pouvoir ainsi directement pointer sur l'objet et le script qui ont causé l'erreur et mieux en identifier la cause.



Rapport de génération

Contenu d’un rapport de génération

Un rapport de génération contient toutes les informations relatives à la génération courante, c’est-à-dire les informations concernant :

Le label de la génération courante

Le rapport de référence

Le modèle et son label

Les packages et leur label

Les scénarios et leur label

Le profil et son label

Les fichiers générés

Remarques :

Le label des packages, scénarios et du profil est commun et se nomme Generator Label. Si le projet utilisé pour la génération est de type Standalone, les éléments packages, scénarios et profil n’apparaissent par dans le rapport. Dans ce cas, ils sont en effet inclus dans le projet et non modifiables individuellement. C’est le projet qui portera le label Generator Label.

Statut de génération des fichiers

Selon que la génération crée un nouveau fichier ou mette à jour un fichier déjà existant, le nom du fichier est précédé par un icône différent. Cet icône dépend du statut de génération du fichier (statut physique du fichier). De plus, on analyse le contenu du fichier généré, lors de la mise à jour d’un fichier existant, pour savoir si le code entre balises est celui généré par défaut. Si ce n’est pas le cas, on signale la présence de code « manuel » entre balises par une main sur l’icône du fichier.

Nouveau fichier

Fichier modifié

Fichier modifié contenant du code manuel

Fichier non modifié

Fichier non modifié contenant du code manuel

Fichier non généré



Statut de comparaison des éléments du rapport

Pour les fichiers générés et pour les fichiers du modèle, des packages et des scénarios, MIA-Generation effectue une comparaison de chaque élément avec son homologue dans le rapport de référence. Le résultat de cette comparaison est un statut par rapport à la référence (statut logique du fichier par rapport à une référence).

Statut de comparaison Description

NEW Nouveau fichier par rapport à la version de référence

MODIFIED Fichier comportant des modifications du code hors balises (modification du modèle ou des scripts) par rapport à la référence

UNMODIFIED Fichier non modifié par rapport à la version de référence

MANUALLY_MODIFIED Fichier comportant des modifications du code entre balises (modification du code manuel) par rapport à la version de référence

MODIFIED_AND_

MANUALLY MODIFIED

Fichier comportant des modifications du code hors et entre balises (modification du modèle ou des scripts et code manuel) par rapport à la version de référence

REMOVED Fichier supprimé par rapport à la version de référence

Si aucun rapport de référence n’est sélectionné, tous les fichiers sont à l’état NEW.

Les statuts de comparaison sont déterminés à partir des checksums (CRC 32 bits) calculées sur les fichiers.

Créer un rapport de génération

Pour créer un rapport de génération, vous devez cocher l'option Generate Report de la boîte de dialogue de lancement de génération. Vous pouvez saisir les informations relatives au rapport :



Figure 110 – Activation du rapport de génération

Consulter le rapport de génération courant

Si la génération de rapport est active (option Generate report au moment de la génération), le rapport courant peut être consulté après la génération depuis le panneau Generation.

Figure 111 – Rapport de génération



Charger un rapport de génération

Il est possible de charger un rapport de génération existant par le menu File > Open > Report.

Sauver un rapport de génération

Un rapport de génération peut être sauvegardé dans un fichier XML par le menu principal File > Save Report. De cette façon il est possible de conserver un rapport dans le but de le comparer à un autre.



Trace de génération Si la génération a été tracée (option Generate trace au moment de la génération), la trace peut être consultée depuis le navigateur de la vue Traces.

Figure 112 – Consultation d'une trace de génération

Une trace est constituée d'une liste de noeuds de génération. Un noeud de génération décrit l'application d'un script sur un objet du modèle.

Pour chaque noeud sont donc mémorisés :

L'objet du modèle sur lequel le script a été appelé

Le script qui a été appelé et ses paramètres

Le texte généré par l'application de ce script sur l'objet du modèle

Les noeuds qui résultent de l'évaluation de ce noeud (lorsqu'un script est évalué sur un objet cela déclenche l'évaluation des scripts qui y sont référencés).

Dans une trace de génération sont mémorisés tous les scripts utilisés. Il est donc possible de tous les lister (menu contextuel Browse > Used scripts).

De la même façon, il est possible de lister tous les scripts en mémoire qui n'ont pas été utilisés par la génération (menu contextuel Browse > Unused scripts).

Ces fonctions permettent de détecter plus facilement les scripts obsolètes qui n'ont plus de raison d'être et qui peuvent être supprimés.



Trace de transformation

Dans le cas ou un scénario de génération intègre une étape de transformation de modèle, un nœud particulier apparaît dans la liste, portant le nom de la transformation.

Figure 113 : Trace de transformation

Pour ce type de nœud, on mémorise le projet de transformation, l’écrivain utilisé par le transformateur, le lecteur utilisé par le générateur pour chargé le modèle résultant de la transformation et l’emplacement de ce dernier.

Suite à une transformation, le modèle résultant est automatiquement chargé de façon que les scripts de génération suivants s’appliquent sur ce nouveau modèle. Ceci entraîne que les traces de génération pour les étapes précédentes ne seront plus disponibles.

De même si l’option Reload model when generation is completed a été cochée, seules les traces de génération relative au modèle initial seront disponibles.

Sauver une trace de génération

Une trace de génération peut être sauvegardée dans un fichier. De cette façon il est possible d'analyser une trace en dehors de MIA-Generation.



Points d’arrêt Un point d’arrêt permet d’interrompre la génération pour faciliter son débogage. Il peut être positionné sur n’importe quel type de scripts (Template, Macro, Service).

Lors de l’exécution d’une génération, si un script portant un point d’arrêt doit être exécuté, la génération est alors interrompue.

La reprise de la génération n’est pas encore supportée et les points d’arrêt ne sont pas sauvegardés.

Opérations de base sur un point d’arrêt

Pour créer un point d’arrêt, utilisez le menu contextuel sur un script Add Break point. Le point d’arrêt est alors créé et activé (Exemple sur un text template ).

Figure 114 : Ajout d’un point d’arrêt

Pour supprimer un point d’arrêt, utilisez le menu contextuel sur un script Remove Break point

Pour désactiver un point d’arrêt, utilisez le menu contextuel sur un script Desactivate Break point

Pour activer un point d’arrêt désactivé, utilisez le menu contextuel sur un script Activate Break point



Figure 115 : Point d’arrêt positionné sur un script

Gérer l’ensemble des points d’arrêt d’un projet

Pour visualiser l’ensemble des points d’arrêt du projet :

Allez sur l’onglet Traces et cliquez sur

Figure 116 : points d’arrêt d’un projet

Déboguer en utilisant les points d’arrêt

Pour exploiter les points d’arrêt activés que vous avez positionnés préalablement, il faut cocher l’option Use breakPoints dans l’onglet et lancer la génération.



Figure 117 : Utilisation des points d’arrêt

Si un script possédant un point d’arrêt activé est appelé, la génération est alors interrompue. La trace est alors dépliée sur le nœud de génération correspondant au script sur lequel le point d’arrêt a été positionné.



Figure 118 : génération interrompue par un point d’arrêt

Point d’arrêt conditionné

Plutôt que de stopper la génération dès la première exécution d’un script sur lequel un point d’arrêt a été positionné, il est possible d’arrêter la génération lors de l’exécution d’un script pour un élément particulier du modèle.

Pour conditionner un point d’arrêt :

1. utilisez le menu contextuel sur un script possédant un point d’arrêt Breakpoints Properties …

2. cocher l’option stops on selected element et choisissez l’élément du modèle

Figure 119 : Sélection d’un élément du modèle pour le point d’arrêt



Apis et notions avancées

Syntaxe des scripts Java MIA-Generation met à votre disposition deux mots-clés current et context ainsi qu'un certain nombre de méthodes vous permettant de manipuler plus facilement les objets du modèle dans les scripts Java.

La variable current Comme un script Java s'évalue sur un objet du modèle, il est nécessaire de récupérer cet objet de manière à personnaliser le résultat du script. Pour cela, dans chaque script Java on peut utiliser la variable current qui contient l'objet courant.

Exemple : Appel de la méthode toString() sur l'objet current

return current.toString();

La variable context La variable context permet de définir des variables utilisables dans d’autres scripts. La variable contexte implémente l'interface mia.gen.openapi.Context. Cette interface fournie des services utiles pour construire un générateur :

des services donnant l'accès aux variables de l'environnement de génération, comme le répertoire de génération par défaut ou le nom du projet courant.

des services permettant de lire ou écrire des valeurs dans un context global.

des services permettant d'accéder au rapport de génération s'il existe .

Le context global peut contenir plusieurs sortes de variables :

les variables "Système" : ces variables sont fournies par MIA-Generation ou créées à partir de la ligne de commande au lancement de l'outil. Ces variables ne peuvent pas être supprimées.

Les variables "Utilisateur" : ces variables sont définies à l'exécution des scripts. Elles peuvent éventuellement surcharger des variables "Système". Dans ce cas, les valeurs initiales des variables "Système" ne seront plus visibles avant un effacement des variables.

Le contexte peut être initialisé au lancement de MIA-Generation. Pour cela, il suffit de placer, en ligne de commande, la liste des variables à stocker dans le contexte (avec leur valeur).

Exemple : Initialisation du contexte

-repertoire c:\\result -version 2



Ceci a pour conséquence de placer les variables repertoire = "c:\result" et version = "2" dans le contexte.

Résumé des méthodes de l'interface com.mia.openapi.gen.Context :

List allInstances(String typeName) Renvoie toutes les instances du type de modélisation spécifié.

List allSubInstances(String typeName) Renvoie toutes les instances du type de modélisation spécifié, ainsi que de ses éventuels sous-types.

void cancelGeneration() Permet d'interrompre un génération.

void clear() Vide le contexte en supprimant toutes les variables (sauf les variables System qui sont simplement réinitialisées).

String get(String key) Retourne une valeur depuis le contexte.

JFrame getFrame() Renvoie une référence à la fenêtre principale de MIA-Generation, si MIA-Generation est en mode graphique.

String getGenerationDirectory() Retourne le répertoire de génération courant.

Report getGenerationReport() Retourne le dernier rapport de génération, si il existe.

String getJDKDirectory() Retourne le répertoire du JDK utilisée par MIA-Generation("c:\jsdk1.4.1" par exemple).

String getLastSavedResourceFilename() Retourne le nom de fichier de la dernière ressource sauvée.

String getMetaModelName() Retourne le nom du méta-model courant.

String getMIADirectory() Retourne le repertoire d'installation de MIA-Generation ("c:\program files\MIA-Generation" par exemple).

String getModelFilePath() Retourne le chamin complet du modèle courant..

String getModelFormat() Retourne le format du modèle courant ("Rational Rose (MDL)" par exemple).

String getProjectFilePath() Retourne le chemin complet du projet courant..

String getProjectName() Retourne le nom du projet.

String getSelectedResourceDefaultFileExtension() Retourne l'extension par défaut du fichier de la ressource sélectionné

String getSelectedResourceFilename() Retourne le nom de fichier de la resource sélectionnée.

String getSelectedResourceModificationTimestamp() Retourne le timestamp de la ressource sélectionnée sous la forme d'une String.

String getSelectedResourceName() Retourne le nom de la resource sélectionnée.

Date getSelectedScriptCreationDate() Retourne la date de création du script sélectionné.

String getSelectedScriptName() Retourne le nom du script sélectionné.

String getSelectedScriptType() Retourne le type du script sélectionné.

String getString(String key) Retourne une représentation textuelle d'une valeur du dictionnaire.



Object getValue(String key) Retourne une valeur depuis le dictionnaire.

boolean hasGenerationReport() Retourne vrai si un rapport de génération est disponible.

boolean isSilentMode() Retourne vrai si MIA-Generation est en mode silencieux.

Set keySet() Retourne sous la forme d'un Set les noms des variables définies dans le contexte.

void remove(String key) Supprime la clé spécifié du contexte.

void set(String key, String value) Ecrit une valeur de type String dans le contexte.

void setString(String key, String value) Ecrit une valeur de type String dans le contexte.

void setValue(String key, Object value) Ecrit une valeur dans le contexte.

int size() Retourne le nombre de variable du contexte.

Collection values() Retourne sous la forme d'une Collection les valeurs du contexte.



Exemple : Utilisation de la variable context dans les scripts

context.set("tab1","\t");

return context.get("tab1");

Les accesseurs

Pour chaque type d'objet du modèle, un certain nombre d’accesseurs de base est fourni. De manière générale :

pour chaque attribut a : une méthode getA() qui renvoie la valeur de l’attribut

Exemple : Attribut name sur le type UMLClass

return current.getName();

Dans une macro définie sur le type UMLClass, on pourra écrire current.getName() puisque le type UMLClass possède un attribut name hérité du type UMLModelElement.

pour chaque rôle r1 de multiplicité 1 : une méthode getR1() qui renvoie l’objet lié au rôle

Exemple : Attribut name sur le type UMLClass

return current.getName();

Dans une macro définie sur le type UMLClass, on pourra écrire current.getName() puisque le type UMLClass possède un attribut name hérité du type UMLModelElement.

pour chaque rôle rN de multiplicité n : une méthode getRN() qui renvoie, sous forme d’un tableau d’objets, les objets liés au rôle.

Exemple

: UMLAttribute[] getAttributes() sur UMLClassifier

On pourra ainsi écrire :

return current.getAttributes();

puisque le type UMLClass possède un role attributes (hérité du type UMLClassifier).



Les appels de scripts

On peut appeler un script sur n'importe quel objet du modèle. Pour cela, l'API de MIA-Generation propose un certain nombre de méthode permettant d'invoquer un script sur un objet. Le tableau suivant résume ces différentes méthodes qui seront détaillées par la suite :

action Cette méthode permet d'appeler un script défini dans MIA-Generation en passant en paramètre le nom du script.

apply La méthode apply, disponible pour tous les types, permet d'enchaîner automatiquement un script sur une liste d'objets. Le résultat de la méthode apply est une chaîne de caractères, résultat de la concaténation de chaque résultat intermédiaire

collect Cette méthode permet de récupérer une liste d’objets liés à l’objet courant en appliquant un script sur une liste d'objets.

select Cette méthode permet, de manière très simple, de récupérer une liste d’objets liés à l’objet courant (par exemple récupérer les attributs publics d’une classe) en appliquent sur une liste d'objets un critère de sélection.

detect Cette méthode permet, de manière très simple, de récupérer un objet lié à l’objet courant (par exemple récupérer l’attribut nommé « Id » d’une classe) en sélectionnant le premier objet répondant à un critère de sélection sur une liste d'objets.

reject Cette méthode fournit le service exactement inverse de la méthode select.

sort Cette méthode trie les objets en fonction d'un script spécifié.

superAction Permet d'appeler un script défini sur le type parent, pour faciliter la redéfinition du ce script sur le type enfant.

Il y a deux façons de référencer un script (script_call) dans ces méthodes d'appels (action, apply, etc.). Vous pouvez référencer le script en utilisant :

un objet String : un script qui n'a aucun paramètre put être référencé directement par son nom,

un objet Call : l'objet Call doit être utilisé pour référencer les scripts qui attendent des paramètres.



La méthode action

Sur n'importe quel objet du modèle, on peut appeler le méthode action. Cette méthode permet d'appeler un script défini dans MIA-Generation en passant en paramètre le nom du script ou un appel de script avec paramètres (instance de mia.gen.openapi.Call). Seuls sont appelables les scripts définis pour le type de l'objet ou l'un de ses super-types.

Object action(script_call)

Description Invoque le script correspondant l'appel script_call spécifié. Le script doit être défini sur le type du receveur ou sur l'un de ses parents. Cette méthode permet d'appeler tout type de script et reste générique. Des méthodes plus spécifiques (getString() pour les appels de scripts retournant du texte ou getList() pour les appels de services) doivent lui être préférées dans la plupart des cas.

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour obtenir le nom d'un objet de type UMLModelElement :

String name = (String) current.action("name");

Attention

: le type de retour de cette méthode est Object. Il peut donc être parfois nécessaire de forcer le type de l'objet renvoyé (technique du cast). Il est alors plus intéressant d'utiliser les méthodes getString et getList.

La méthode getString

La méthode getString permet d'appeler un template ou une macro et de renvoyer la chaîne de caractères résultat de l'évaluation du template ou de la macro.

Un appel à getString() est strictement équivalent à un appel à action() suivi d'un cast en String.

String getString(script_call)

Description Invoque le script correspondant l'appel script_call spécifié. Le script est supposé renvoyer une chaîne de caractères (String). GetString() retourne une représentation textuelle de l'évaluation du script en utilisant la méthode String.valueOf(Object).

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour obtenir le nom d'un objet de type UMLModelElement :

String name = current.getString("name");



La méthode getList

La méthode getList permet d'appeler un service et d'obtenir la liste des objets renvoyés par ce service.

La méthode getList va formater les objets renvoyés par un service de sorte à toujours obtenir une instance de java.util.List. Si le service renvoie un seul objet du modèle, getList renvoie une liste contenant cet objet. Si le service renvoie un Iterator ou un tableau d'objets, ils seront convertis en List. Ainsi on peut appeler des services de façon homogène, sans se soucier de savoir comment ont été implémentés ces services.

java.util.List getList(service_call)

Description Invoque le service correspondant à l'appel service_call spécifié le résultat de l'évaluation du service est convertie en un objet de type List : les objets de type Collection, Iterator, les tableaux sont convertis en objets de type List. Pour tout autre type d'objet, une liste contenant un seul élément est créée.

Paramètres service_call : le service à évaluer (String, Call) Exemple Pour obtenir tous les attributs définis sur un objet de type UMLClass :

List attributes = current.getList("attributes");



Les méthodes de conversion de type

Les méthodes disponibles dans MIA-Generation ont toujours pour type de retour des objets. Cependant il est parfois plus commode de manipuler dans les scripts des types Java primitifs plutôt que leurs classes Wrapper. De la même façon, certains transtypages ou de conversions peuvent être factorisés au sein de méthodes génériques. Cette section présente ces différentes méthodes.

boolean getBoolean(script_call)

Description Invoque le script correspondant à l'appel script_call, script dont l'évaluation correspond à une valeur de type booléen. Retourne true si le résultat de l'évaluation du script est Boolean.TRUE ou est égal, sans tenir compte de la casse, à la chaîne "true" (utilisation de Boolean.valueOf(String)).

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour vérifier si une UMLClass est abstraite :

boolean isAbstract = current.getBoolean("abstract");

byte getByte(script_call)

Description Invoque le script correspondant à l'appel script_call, script dont l'évaluation correspond à une valeur de type byte. Retourne une valeur de type byte si le résulat est une instance de Number ou est une chaîne représentant un byte. Lève une exception NumberFormatException dans les autre cas.

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour récupérer le résultat d'un script renvoyant un byte :

byte b = current.getByte("myByteScript");

char getChar(script_call)

Description Invoque le script correspondant à l'appel script_call, script dont l'évaluation correspond à une valeur de type char. Retourne une valeur de type char si le résulatest une instance de Character ou est une chaîne représentant un byte. Lève une exception IllegalArgumentException dans les autre cas.

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour récupérer le résultat d'un script renvoyant un Character :

char c = current.getChar("myCharacterScript");

double getDouble(script_call)

Description Invoque le script correspondant à l'appel script_call, script dont l'évaluation correspond à une valeur de type double. Retourne une valeur de type double si le résulatest une instance de Number ou est une chaîne représentant un double (utilisation Double.parseDouble(String)). Lève une exception NumberFormatException dans les autre cas.

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour récupérer le résultat d'un script renvoyant un double :

double d = current.getDouble("myDoubleScript");



float getFloat(script_call)

Description Invoque le script correspondant à l'appel script_call, script dont l'évaluation correspond à une valeur de type float. Retourne une valeur de type float si le résulatest une instance de Number ou est une chaîne représentant un float (utilisation Float.parseFloat(String)). Lève une exception NumberFormatException dans les autre cas.

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour récupérer le résultat d'un script renvoyant un float :

float f = current.getFloat("myFloatScript");

int getInt(script_call)

Description Invoque le script correspondant à l'appel script_call, script dont l'évaluation correspond à une valeur de type int. Retourne une valeur de type int si le résulatest une instance de Number ou est une chaîne représentant un int (utilisation Integer.parseInt(String)). Lève une exception NumberFormatException dans les autre cas.

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour récupérer le résultat d'un script renvoyant un int :

int i = current.getInt("myIntegerScript");

long getLong(script_call)

Description Invoque le script correspondant à l'appel script_call, script dont l'évaluation correspond à une valeur de type long. Retourne une valeur de type long si le résulatest une instance de Number ou est une chaîne représentant un long (utilisation Long.parseLong(String)). Lève une exception NumberFormatException dans les autre cas.

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour récupérer le résultat d'un script renvoyant un long :

long l = current.getLong("myLongScript");

short getShort(script_call)

Description Invoque le script correspondant à l'appel script_call, script dont l'évaluation correspond à une valeur de type short. Retourne une valeur de type short si le résulatest une instance de Number ou est une chaîne représentant un short (utilisation Short.parseShort(String)). Lève une exception NumberFormatException dans les autre cas.

Paramètres script_call : le script à évaluer (String, Call) Exemple Pour récupérer le résultat d'un script renvoyant un short :

short s = current.getShort("myShortScript");



La méthode apply

La méthode apply, disponible pour tous les types, permet d'enchaîner automatiquement un script sur une liste d'objets. Cette méthode prend en paramètres une liste d’objets et un script qui va s'appliquer sur chacun des objets de la liste. Elle concatène dans une chaîne de caractères les résultats de l'évaluation du script.

La liste des objets peut être de plusieurs natures :

java.util.Collection

Object[] (tableau d’objets)

java.util.Iterator

String (le nom d’un service)

Un objet Call pour référencer un service avec paramètres

Exemple : Corps d'une macro définie sur le type Class

return current.apply("attributes","codeCpp");

Cette macro récupère tous les attributs de la classe et pour chacun d'eux appelle le script codeCpp. Le résultat de cette macro est une chaîne de caractères, résultat de la concaténation de chaque résultat intermédiaire.

Il et possible de spécifier un séparateur entre chaque résultat intermédiaire : il suffit de passer ce séparateur comme troisième paramètre de la méthode apply.

Exemple : Utilisation du séparateur dans un apply

return current.apply("attributes","codeCpp","\n");

Cette macro récupère tous les attributs de la classe et pour chacun d'eux appelle le script codeCpp. Chaque résultat de l'évaluation de codeCpp est suivi d'un retour à la ligne.

String apply(object_list, script_call [, String separator])

Description Concatène dans une String les résultats de l'évaluation du script spécifié sur chaque objet de la liste. Cette méthode appelle le script spécifié, calcule une réprésentation textuelle du résultat de l'évaluation en utilisant le méthode String.valueOf(Object)et concatène ces résultats dans un objet String.

Paramètres objects_list : les objets à évaluer qui peuvent être : - une liste d'objets (java.util.Collection, java.util.Iterator, Object[]) – un nom de service (String) ou un descripteur d'appel(Call)

script_call : le script à appliquer sur chaque objet de la liste (String, Call)

separator (optional) : un séparateur optionnel qui sera inséré entre chaque évaluation

Exemple Pour retourner une chaîne de caractères contenant les noms des attributs d'une classe, séparés par une virgule : current.apply("attributes", "name", ",");



La méthode collect Cette méthode permet, de manière très simple, de récupérer une liste d’objets liés à l’objet courant.

Cette méthode prend en paramètres une liste d’objets et un script qui va s'appliquer sur chacun des objets de la liste.

Le résultat est une instance de java.util.List et contient les résultats de l'évaluation du script sur chacun des objets de la liste.




java.util.Iterator




// Ce code récupère tous les types des attributs d'une classe

return current.collect("attributes","type");

Il et possible de spécifier un troisième paramètre de type booléen pour indiquer s'il faut ou non aplatir la liste d'objets renvoyés (la valeur par défaut est false).

Exemple : Utilisation du paramètre

// pour un package, renvoie une liste de liste d'attributs à plat

return current.collect("classes","attributes", true);

java.util.List collect(object_list, script_call, boolean flatcollect)

Description Retourne une liste d'objets par l'évaluation d'un script (spécifié par script_call) sur une liste d'objets initiale. La méthode appelle le script spécifié sur chaque objet de la liste initiale et crée une autre liste contenant les résultats des évaluations.



flatcollect : ce booléen permet d'aplatir le résultat final si les résultats intermédiaires sont des listes.

Exemple Pour obtenir tous les attributs des classes d'un UMLPackage : List allAttributes = current.collect("classes", "attributes", true);



La méthode select Cette méthode permet, de manière très simple, de récupérer une liste d’objets liés à l’objet courant (par exemple récupérer les attributs publics d’une classe).

Cette méthode prend en paramètres une liste d’objets, un script qui va s'appliquer sur chacun des objets de la liste, et un objet qui servira de critère de sélection.

Le résultat est une instance de java.util.List et contient tous les objets de la liste pour lesquels l’évaluation du script est égal au critère passé en paramètre.




java.util.Iterator




return current.select("attributes","visibility","public");

Cette macro récupère tous les attributs de la classe et pour chacun d'eux appelle le script visibility. Elle sélectionne les attributs pour lesquels l'évaluation de visibility vaut la chaîne de caractères "public".

java.util.List select(object_list, script_call, Object value)

Description Retourne une liste d'objets pour laquelle l'évaluation du script spécifié par script_call correspond à la valeur value attendue (inverse de la méthode reject()). La méthode appelle le script spécifié sur chaque objet de la liste initiale et conserve seulement ceux pour lesquelles l'évaluation du script est égale à la valeur attendue



value : la valeur attendue pour l'évaluation du script (peut être null). Exemple Pour sélectionner seulement les attributs "public" d'une UMLClass :

List attributes = current.select("attributes", "visibility", "public");



La méthode detect Cette méthode permet, de manière très simple, de récupérer un objet lié à l’objet courant (par exemple récupérer l’attribut nommé « Id » d’une classe).


Le résultat est une instance de Object et représente le premier objet de la liste pour lequel l’évaluation du script est égal au critère passé en paramètre.




java.util.Iterator




return current.detect("attributes","name","Id");

Ce code renvoie l'attribut de la classe dont le nom est "Id".

Object detect(object_list, script_call, Object value)

Description Retourne le premier objet pour laquelle l'évaluation du script spécifié par script_call correspond à la valeur value attendue La méthode appelle le script spécifié sur chaque objet de la liste initiale et si une évaluation correspond au résultat attendu, renvoie l'objet correspondant.



value : la valeur attendue pour l'évaluation du script (peut être null). Exemple Pour obtenir le premier attribut "public d'une UMLClass :

UMLAttribute attribute = (UMLAttribute) current.detect("attributes", "visibility", "public");



La méthode reject Cette méthode fournit le service exactement inverse de la méthode select.


Le résultat est une instance de java.util.List et contient tous les objets de la liste pour lesquels l’évaluation du script est différent du critère passé en paramètre.




java.util.Iterator




return current.reject("attributes","visibility","public");

java.util.List reject(object_list, script_call, Object value)

Description Retourne une liste d'objets pour laquelle l'évaluation du script spécifié par script_call diffère de la valeur value (inverse de la méthode select()). La méthode appelle le script spécifié sur chaque objet de la liste initiale et conserve seulement ceux pour lesquelles l'évaluation du script est égale à la valeur attendue.



value : la valeur dont l'évaluation du script doit être différente (peut être null). Exemple Pour obtenir tous les attributs non privés d'une UMLClass :

List attributes = current.reject("attributes", "visibility", "private");



La méthode sort Cette méthode permet de trier une liste d’objets. Cette méthode prend en paramètres une liste d’objets, un script qui va s'appliquer sur chacun des objets de la liste.

Le résultat est une instance de java.util.List et représente la liste des objets triée par odre croissant. Pour un ordre décroissant, il suffit de passer un troisième paramètre (de type booléen : true pour croissant et false pour décroissant).

La liste des objets peut être de plusieurs types :



java.util.Iterator




return current.sort("attributes","name");

Cette macro renvoie une liste d'attributs triés en fonction de leurs noms.

java.util.List sort(object_list, script_call [, boolean ascendingOrder])

Description Trie les objets en fonction du script spécifié. Le script est appliqué à chaque objet de la liste. Ensuite, l'ordre des objets est déterminé en comparant les différentes résultats des évaluations, qui doivent implémenter l'interface java.lang.Comparable (comme java.lang.String).

Paramètres objects_list : les objets à trier qui peuvent être : - une liste d'objets (java.util.Collection, java.util.Iterator, Object[]) – un nom de service (String) ou un descripteur d'appel(Call)

script_call : le script déterminant l'ordre des objets (String, Call)

ascendingOrder (optional) : booléen déterminant si l'odre de tri est ascendant ou non (vrai par défaut).

Exemple Pour trier les attributs d'une UMLClass en fonction de leur nom : List sortedAttributes = current.sort("attributes", "name");



La méthode superAction

Sur n'importe quel objet du modèle, on peut appeler le méthode superAction. Cette méthode permet d'appeler un script défini sur un type parent en passant en paramètre le nom du script ou un appel de script avec paramètres (instance de mia.gen.openapi.Call). Cette méthode est très utile quand on souhaite redéfinir un script sur un type enfant.

Object superAction(script_call)

Description Invoque le script correspondant l'appel script_call spécifié. Le script doit être défini sur un des types parents du receveur. Cette méthode permet d'appeler tout type de script et reste générique.

Paramètres script_call : le script à évaluer (String, Call)



La méthode getPropertyValue

Cette méthode, définie sur UMLModelElement, permet d'obtenir la valeur d'un tagValue particulier rattaché à l'objet courant, si le modèle UML importé vient de Rose.

Cette méthode prend en paramètres le nom de l'onglet Rose du tag et le nom de la propriété. Le résultat est une chaîne de caractères contenant la valeur du tag.


return current.getPropertyValue("SQL","nomTable");



Appel des scripts avec paramètres

Nommage des paramètres

Les noms des paramètres doivent être des identifiants Java valides. De plus, les mots-clés current et context sont interdits.

Typage des paramètres

Les paramètres des scripts sont obligatoirement des objets Java™ - c''est-à-dire des instances ou sous-instances de java.lang.Object. Pour l'appel depuis les templates, une conversion automatique des types primitifs vers leurs objets Wrapper (ex : int vers Integer) est effectuée.

Appel des scripts avec paramètres depuis les templates

L'accès aux paramètres dans les templates doit respecter les contraintes suivantes :

On appelle des scripts seulement sur l'objet current.

Pour accéder à ces paramètres, on doit se situer dans une zone entre balises.

L'accès aux paramètres se fera via un mot-clé particulier args et la notation pointée pour distinguer nom de script et nom de paramètre (ex : args.myParameter).

Un script défini sur le type courant peut être utilisé comme paramètre.

Le résultat d'un appel de paramètre seul (ex : [[args.myParameter]]) dans un template, est converti en String en tuilisant la méthode java.lang.String.valueOf(Object).

La liste des paramètres d'appel d'un script sera passée entre parenthèse.

L'appel d'un script sans paramètre au sein d'un template peut se faire simplement par son nom mais également par son nom suivante des parenthèses ouvrantes et fermantes.

Types primitifs et chaînes de caractères comme paramètres

Vous pouvez directement utiliser dans les templates les types primitifs (entiers, booléens, etc.) et les chaînes de caractères (entre guillemets) comme paramètres. Ils seront automatiquement convertis vers les objets Java correspondant (puisque tous les paramètres sont obligatoirement de type Object) :

Expression Object Java

true java.lang.Boolean.TRUE

false java.lang.Boolean.FALSE

1 java.lang.Integer

1.2 java.lang.Float

'a' java.lang.Character

"text" Java.lang.String

null null



Exemples d'appels de script depuis un template :

Les exemples suivants se basent sur les scripts suivants définis sur UMLClass :

String name()

String formatText(String text)

java.io.File getFile()

java.io.File getPackageFile(UMLPackage pkg)

UMLAttribute filteredAttributes(String s, Boolean b)

UMLPackage package()

UMLClass associateTable()

L'appel des scripts se fait sur le template suivant défini sur UMLClass :

String myTemplate(String str, UMLPackage pkg)

Tous les appels se font implicitement sur current et uniquement sur cet objet. Un toString() implicite est effectué pour les macros, services et templates. Si l'objet renvoyé est null alors on affiche la chaîne "null".

// String.valueOf() sur le résultat de la macro name [[name]]

// String.valueOf() sur le résultat de la macro formatText // On peut directement référencer des chaînes de caractères comme paramètre [[formatText("Test")]]

// String.valueOf() on returned package [[package]]

// String.valueOf() on returned java.io.File [[getFile()]]

Il n'y a pas de notation pointée autre que celle permettant d'accéder aux paramètres via le mot-clé args. Le passage de paramètres au sein du template se fait de la façon suivante :

// String.valueOf() sur la collection de UMLAttrribute renvoyé par le service [[filteredAttributes(args.str, true)]]

// Accès au paramètre str du script myTemplate // et String.valueOf() sur le paramètre obtenu [[args.str]]

// Propagation du paramètre str vers la macro formatedString // et String.valueOf() du résultat [[formatText(args.str)]]



Il est possible d'utiliser les scripts de current comme paramètres.

// Utilisation d'un service package comme paramètre

[[getPackageFile(package)]]



Utilisation des paramètres dans les scripts Java : macros et services

Accès aux paramètres dans les scripts Java™

Dans les scripts Java™, on pourra utiliser de façon transparente les paramètres déclarés sur le script courant.

Exemple : String concat(String s1, String s2)

return s1 + s2;

Passage de paramètres à un script en Java

Le passage de paramètres à un script Java se fait en utilisant une instance de la classe mia.gen.openapi.Call.

Cette classe a pour fonction de créer des appels aux scripts, appels utilisés dans les méthodes de MIAObject comme action, apply, etc. Notez que la création d'une instance de Call n'invoque pas directement le script référencé mais initialise un "descripteur" qui sera utilisé à l'évaluation de la méthode.

Bien que une instance de Call puisse référencer un script sans paramètre (en utilisant le constructeur Call(String)), cette classe est avant tout destinée aux scripts ayant des paramètres.

Par exemple, une utilisation typique du Call sera :

current.action(new Call("myScript", myFirstParameter,

Boolean.TRUE, new Integer(1)));

La classe Call fournit 6 constructeurs en standard permettant d'appeler des scripts de 0 à 5 paramètres.

Call(String name)

Call(String name, Object param1)

Call(String name, Object param1, Object param2)

Call(String name, Object param1, Object param2, Object param3)

Call(String name, Object param1, Object param2Object param3, Object param4)

Call(String name, Object param1, Object param2, Object param3, Object param4, Object param5)

La sous-classe CallN de Call peut être utilisée pour des scripts ayant un nombre quelconque d'arguments : dans ce cas, les paramètres sont passés sous la forme d'un tableau d'objets ou d'une collection.

CallN(java.lang.String name, java.util.Collection parameters)

CallN(java.lang.String name, java.lang.Object[] parameters)



Depuis un script Java™, on peut utiliser les objets Call ou CallN dès qu'une méthode de MIAObject attend une référence à un script.

Pour référencer un script avec paramètres dans la méthode action, on utilisera la syntaxe suivante :

Object action(new CallN(actionName, Object[] parameters));

ou jusqu'à cinq paramètres la syntaxe de Call

Object action(new Call(actionName, parameter1, parameter2));

La syntaxe sera aussi valable pour toutes les méthodes de MIAObject : getString, getList, les autres méthodes de conversion de types et apply, select, detect, sort, collect, reject.

Exemple : Appel à la macro String concat(String str1, String str2)

String s1 = "Test de";

String s2 = " de concaténation";

return current.getString(new Call("concat", s1, s2));

ou encore

String s1 = "Test de";

String s2 = " de concaténation";

return current.getString(new CallN("concat", new Object[] {s1, s2}));

Accès à des composants Java externes depuis MIA-Generation

Vous pouvez dans les macros et les services utiliser tout composant Java externe à MIA-Generation. Le répertoire tools/lib dans le répertoire d’installation de MIA-Generation est destiné à recevoir les composants Java de l’utilisateur. Les fichiers JAR et CLASS présents dans ce répertoire sont ajoutés au classpath de MIA-Generation à l’exécution et ainsi accessibles dans les scripts.

L’accès à des composants Java externes se passe donc en deux étapes :

1. Copiez vos composants (fichiers JAR ou classes compilées) dans le répertoire tools/lib

2. Utilisez vos classes dans les scripts

Il faudra pour cela les référencer avec leur nom complet, incluant le nom de leur package.



Gestion avancée des modèles

Profils des modèles UML

Stéréotypes

Les stéréotypes définis sur les objets sont récupérés par MIA-Generat ion for UML

puisqu'il s'agit d'objets en tant que tels du modèle.

Un stéréotype, de manière implicite, est un moyen de définir un nouveau type d'objet. C'est pourquoi, MIA-Generation

donne la possibilité de manipuler les objets stéréotypés comme des instances d'un type particulier.

Par exemple, à partir de toutes les classes stéréotypées <<Table>>

dans un modèle, MIA-Generation peut en faire non pas des instances de UMLClass

mais des instances d'un type Table, sous-classe de UMLClass.

Tagged-values

Les tagged-values définies sur les objets sont récupérés par MIA-Generation pour UML puisqu'il s'agit d'objets en tant que tels du modèle.

MIA-Generation

permet une utilisation très simple de ces objets, grâce à la méthode getPropertyValue qui récupère directement la valeur d'un tag à partir de son nom.

Contraintes

Cette notion concerne la phase de modélisation, puisque c'est lors de la création du modèle que doivent être vérifiées les contraintes.

Lorsque le modèle est donné à MIA-Generation, on suppose que les contraintes ont été satisfaites et que le modèle est correct.

Si ce n'est pas le cas, MIA-Generation

peut alors servir à définir des scripts de contrôle du modèle. Pour cela il suffit d'écrire les scripts qui, plutôt que de générer du code, vont générer un rapport de cohérence du modèle basé sur les contraintes exprimées dans le profil.

Particularités de l'import XMI

Certains AGL exportent leurs fichiers XMI sans indiquer la version UML utilisée. MIA-Generation vous demandera alors d'indiquer la version UML du fichier à importer.

Si vous utilisez MIA-Generat ion Developer en mode silencieux, vous pouvez spécifier la version UML à utiliser dans le fichier de configuration :

<MIA-Generation>metamodels\UML\connectors\import_xmi.ini.

Exemple :

defaultUMLVersion = 1.3



Particularités de l'import Rational Rose

Types de fichiers chargés

Par défaut, les fichiers Rose importés sont ceux avec l'extension MDL. Cependant, il est aussi possible de charger tout type de fichier Rose, comme par exemple les fichiers PTL (fichiers d’export) et les fichiers CAT (catégorie).

Chargement des propriétés des fichiers CAT

Pour les fichiers CAT, MIA-Generation vous demande s'il faut charger les propriétés par défaut. Il s'agit des valeurs par défaut des TaggedValues créées dans Rose qui ne sont pas présentes dans les fichiers CAT. Si vous souhaitez les charger, vous devez indiquer le fichier qui contient ces valeurs par défaut : c'est généralement un fichier de type PTY ou éventuellement un MDL.

Si vous utilisez MIA-Generat ion Developer en mode silencieux, vous pouvez spécifier le fichier de propriétés Rose à charger dans le fichier de configuration :

<MIA-Generation>\metamodels\UML\connectors\import_rose.ini.

Exemple :

LoadPropertiesEnabled = true

LoadPropertiesFilename = C:\\Modeles\\properties.pty

Variables d’environnement Rose

Un fichier MDL est généralement découpé en plusieurs fichiers intermédiaires (les fichiers CAT). L'emplacement de ces fichiers peut être indiqué de manière relative en faisant appel à des variables d'environnement Rose. Si c'est le cas, vous devez indiquer la valeur des variables utilisées dans le fichier :

<MIA-Generation>\metamodels\UML\connectors\import_rose.ini.

Exemple :

$CURDIR = C:\\analyse\\modeles

Comme séparateur de répertoire vous devez utiliser soit le caractère slash ('/') soit deux caractères anti-slash ('\\').

Ce fichier est lu à chaque chargement d'un fichier Rose.



Développer des imports de modèles spécifiques

L'architecture de MIA-Generation est assez ouverte pour permettre à chacun de créer ses propres analyseur de modèles et de les rendre accessibles dans MIA-Generation.

La création d'imports de modèles personnalisés se fait en trois phases :

Composant Java d'import

La première étape est de créer un composant Java capable d'instancier un modèle. Pour cela, il faut faudra écrire une classe Java héritant de la classe abstraite com.mia.openapi.io.model.ModelReader et implémenter la méthode readModel().

Voici un exemple d'implémentation de la méthode readModel(File, MIAObjectFactory) :

import java.io.*; import java.util.*; import metamodel.UML.model.*; import com.mia.openapi.io.*;

public class UMLTestReader extends ModelReader {

public Collection readModel( File modelFile, MIAObjectFactory objectFactory) throws ConnectorException { try { // open the model file and read the data InputStream in = new FileInputStream(modelFile); ... // controls the user has not cancelled the import if (getContext().isAborted()) throw new ConnectorAbortedException(); // write something to the import console getContext().getLog().write(Log.Level.INFO, "Model has been read, now we instantiate MIAObjects"); // creates a MIA model UMLObjectFactory umlFactory = (UMLObjectFactory) objectFactory; UMLModel myModel = umlFactory.newUMLModel(); myModel.setName("TestModel");

UMLClass myClass = umlFactory.newUMLClass(); myClass.setName("TestClass");

myModel.ownedClassifiersAdd(myClass); return Collections.singletonList(myModel); } catch (IOException e) { throw new ConnectorNestedException(e); } } }

Pour plus de détails, voir le documentation Javadoc™ disponible dans le répertoire :

<MIA-Generation>\help\javadoc



Fichier de configuration XML

Vous devez ensuite créer un fichier XML, nommé "connectorFactory.xml" qui permettra d'enregistrer votre import auprès de MIA-Generation.

Ce fichier XML déclarera une liste de lecteurs de modèles. Pour chaque lecteur de modèle, on déclarera :

Un identifiant. Une fois affecté, vous êtes supposé ne plus changer cet identifiant.

Un nom, qui sera celui affiché à l'utilisateur. Il est préférable que ce nom ne change pas par

la suite, car il sera par exemple utilisé pour paramétrer le lancement d'une génération en batch.

Le type de lecteur : "file" si le lecteur se base sur l'analyse d'un fichier source (dans ce cas

une boîte de dialogue est affichée à l'utilisateur pour sélectionner un fichier lors de l'import de modèle), "unspecified" dans le autres cas (connexion à une base de donnée, utilisation d'APIs pour se connecter à un AGL, etc.)

Le nom de la classe Java qui définit le lecteur de modèle (sous-classe de com.mia.openapi.io.mdel.ModelReader).

Si le lecteur de modèle est de type "file", vous pouvez spécifier des extensions de fichiers qui seront affichées dans la boîte de dialogue d'import. Pour chaque extension, on précise :

L'extension du fichier

Une description, qui sera affichée à l'utilisateur

Si cette extension est celle qui doit être sélectionnée par défaut, on affecte la valeur "true" à l'attribut "default". Si aucune extension "default" n'est spécifiée, alors la boîte de dialogue affichera "all supported files", qui sera l'union des différentes extensions spécifiées ici.

Chaque lecteur de modèle peut de plus spécifier des propriétés. Une propriété est une paire nom/valeur. Vous pouvez spécifier autant de propriétés que vous voulez, avec les noms et valeurs que vous voulez.

Ce fichier XML sera de la forme suivante :

<?xml version="1.0"?> <connectors> <reader id = "UML.TestReader" name = "UML - My Model Reader" kind = "file" class = "test.MyModelReader"> <fileExtensions> <fileExtension extension = "xml" description="XML files (*.xml)" default="true"/> <fileExtension extension = "xmi" description="XMI files (*.xmi)"/> </fileExtensions> <properties> <property name = "loaderVersion" value = "2.1"/> <property name = "configFile" value = "myLoader.ini"/> </properties> </reader> </connectors>

Fichier JAR contenant le composant d'import

Vous devez enfin créer un fichier JAR contenant



toutes les classes Java nécessaires à l'import

le fichier XML déclarant votre import.

Placez ce fichier JAR dans le répertoire "connectors" de votre méta-modèle (par exemple "<MIA-Generation>\metamodels\UML\connectors").

Ce fichier sera lu au démarrage de MIA-Generation, et votre import apparaîtra dans la liste des imports possibles.



Exploitation du rapport de génération dans les scripts Un rapport de génération peut être utilisé pour effectuer des actions en fonction des fichiers générés. Pour cela, on peut lancer dans la fenêtre de rapport l’évaluation d’un scénario de génération de visiblilité Report grâce au bouton Generate.

Figure 120 – Rapport de génération

Le scénario de génération de visiblilité Report lance des scripts utilisant les informations du rapport à travers un ensemble d’objets techniques. Les paragraphes suivants expliquent la façon de récupérer et d’exploiter ces objets.

Accès au rapport de génération

La variable context permet de définir ou d'accéder à des variables globales utilisables dans tous les scripts. Elle permet également d’accéder au rapport de génération courant dans les scripts grâce au message context.getGenerationReport(). Cette méthode renvoie null si aucun rapport de génération n'est disponible. On peut aussi tester l'existence d'un rapport de génération en appelant la méthode context.hasGenerationReport().

Exemple : Accès au rapport de génération dans les scripts

// initialize la variable report avec le rapport courant s’il existe

com.mia.openapi.gen.report.Report report = context.getGenerationReport();



L’objet Report

Pour l’objet rapport de génération, un certain nombre d’accesseurs de base sont fournis. Pour accéder aux informations générales du rapport :

getLabel () : renvoie une valeur de type String

getReferenceReportLabel () : renvoie une valeur de type String

getReferenceReportFilename() : renvoie une valeur de type String

getCreationDate() : renvoie une valeur de type java.util.Date

Exemple :

com.mia.openapi.gen.report.Report report = context.getGenerationReport();

String label = report.getLabel();

Pour accéder aux informations relatives aux fichiers générés :

getReportGeneratedFiles() : renvoie une liste d’objets de type ReportGeneratedFile

getReportGeneratedFiles(ComparisonStatus status) : renvoie une liste d’objets de type ReportGeneratedFile filtré sur le statut de comparaison

getReportGeneratedFiles(GenerationStatus status) : renvoie une liste d’objets de type ReportGeneratedFile filtré sur le statut de génération

Pour accéder aux informations relatives respectivement au modèle, aux packages et aux scénarios :

getReportModelFiles() : renvoie une liste d’objets de type ReportModelFile

getReportPackages() : renvoie une liste d’objets de type ReportPackage

getReportScenarios() : renvoie une liste d’objets de type ReportScenario

getReportProfile() : Renvoie le profil utilisé, de type ReportProfile

getReportProject() : Renvoie le projet utilisé, de type ReportProject

Les objets ReportGeneratedFile

Pour l’objet ReportGeneratedFile, un certain nombre d’accesseurs de base sont fournis :


getFilename() : renvoie une valeur de type String

getComparisonSatus() : renvoie une valeur de type ReportComparisonStatus

getGenerationSatus () : renvoie une valeur de type ReportGenerationStatus

getReport() : renvoie une valeur de type Report

isManuallyModified() : renvoie une valeur de type Boolean

getFileChecksum() : renvoie une valeur de type Long

getGeneratedCodeChecksum() : renvoie une valeur de type Long



getUserCodeChecksum() : renvoie une valeur de type Long

Les objets ReportModelFile, ReportPackage, ReportScenario, ReportProfile

Pour les objets ReportModelFile, ReportPackage, ReportScenario, ReportProfile, un certain nombre d’accesseurs de base sont fournis :






Les objets ReportProject

Pour l'objet ReportProject, un certain nombre d’accesseurs de base sont fournis.






getMainScenarioName() : renvoie une valeur de type String

isStandaloneProject() : indique si le projet est de type standalone.

Le type ReportComparisonStatus

Pour le type ComparisonStatus, il existe 6 valeurs :

ReportComparisonStatus.NEW

ReportComparisonStatus.MODIFIED

ReportComparisonStatus.UNMODIFIED

ReportComparisonStatus.MANUALLLY_MODIFIED

ReportComparisonStatus.MODIFIED_AND_MANUALLLY_MODIFIED

ReportComparisonStatus.REMOVED

Le type ReportGenerationStatus

Pour le type ReportGenerationStatus, il existe 4 valeurs :

ReportGenerationStatus.NEW

ReportGenerationStatus.MODIFIED

ReportGenerationStatus.UNMODIFIED

ReportGenerationStatus.REMOVED

MIA-Generation – Manuel Utilisateur - MIA-Generation Developer 148


MIA-Generation Developer

Présentation MIA-Generat ion Developer est l'application qui va vous permettre d'effectuer des générations de masse une fois vos générateurs développés et validés.

MIA-Generat ion Developer permet à tout utilisateur de générer du code sans avoir à se soucier de la façon dont le générateur a été écrit et packagé.

Concepts de base

Un projet de génération regroupe un ensemble de scripts de génération et scénarios. Un projet définit un générateur, basé sur l'utilisation d'un méta-modèle, sans être lié à tel ou tel modèle physique. C'est une évaluation du générateur qui fera appel à des modèles physiques pour son exécution.

Un scénario décrit des enchaînements d'évaluation de scripts.

Le modèle ne fait pas partie du projet mais constitue le paramètre d'entrée de votre générateur.

Le rapport de génération

Le lanceur regroupe les concepts ci-dessus ainsi que des options de générations choisies par l'utilisateur



Interface Utilisateur L'interface utilisateur de MIA-Generation Developer est composée de plusieurs parties :

Une barre de menus

Une barre d'icônes

Des navigateurs, sur la gauche, permettant de visualiser les lanceurs, les résultats, les

métriques (nécessite le module Analysis)

Une zone d'édition de l'élément sélectionné dans le navigateur, sur la droite

Figure 121 - Interface MIA-Generation Developer

Les opérations suivantes sont accessibles depuis la barre de raccourcis :

Icône Description

Chargement d'un élément (projet, package, etc.)

Sauvegarde de l'élément sélectionné dans le navigateur

Rechargement du projet courant

Rechargement du modèle courant



Création d'un nouveau lanceur de génération

Lancement de la dernière génération. Un historique des dernières générations lancées est conservé, accessible par un menu déroulant.

Sélection de l'élément précédent

Sélection de l'élément suivant



Génération

Création d'un lanceur Pour lancer une génération, il faut d'abord créer un lanceur, qui conservera l'ensemble des informations nécessaires :

- un projet

- un scénario

- un modèle

- des options (mode de génération, répertoire de génération, …)

Pour créer un lanceur, vous pouvez utiliser :


- le menu principal File > New > Launcher,

- le menu contextuel du navigateur New > Launcher.

Pour sauvegarder un lanceur :

- sélectionnez le lanceur dans le navigateur.

- lancez la sauvegarde via le bouton

de la barre d'outils. Le même service est fourni par le menu principal File > Save ou File > Save as … si vous voulez changer la destination de sauvegarde, ainsi que par le menu contextuel.

Au démarrage de Mia-Generation, les lanceurs présents dans le répertoire "<Mia-Genaration>\launchers" sont chargés. Par défaut, les lanceurs sont donc sauvés dans ce répertoire.

Sélection d'un projet

Le premier paramètre d'un lanceur est le générateur. Au moment de la génération, le lanceur chargera de lui-même le projet de génération s'il n'est pas déjà chargé.

Sélection du scénario de génération

Un scénario décrit des enchaînements d'évaluation de scripts. Votre projet pouvant contenir plusieurs scénarios, vous pouvez sélectionner le scénario à générer dans la liste des scénarios.

Sélection du modèle

Il est nécessaire d'indiquer le format de lecture du modèle sur lequel le générateur va être lancé. Au moment de la génération, le lanceur chargera de lui-même le modèle s'il n'est pas déjà chargé.



Synchroniser le projet

Après avoir lancé une génération, si le projet est modifié extérieurement, pendant la période où il est chargé dans MIA-Generation, il est possible de forcer la synchronisation en rechargeant le projet avec le

bouton de la barre d'outils.

Synchroniser le modèle

Si le modèle est modifié extérieurement, pendant la période où il est chargé dans MIA-Generation, il est

possible de forcer la synchronisation en rechargeant le modèle avec le bouton de la barre d'outils.

Options de génération

Les différentes options de génération sont décrites dans la section correspondante de MIA-Generation Architect.

Lancement de la génération Lorsque vous avez indiqué les informations du lanceur et choisi les options de génération, il ne vous reste

plus qu'à lancer la génération à l'aide du bouton Generate ou du bouton de la barre d'outils.

Le bouton conserve un historique des derniers lanceurs utilisés, et re-lance par défaut le dernier.

Figure 122 : Historique des lanceurs

Consulter le résultat d'une génération Le navigateur Results permet de consulter le résultat de la génération ainsi que le rapport de génération.

Se reporter à la section correspondante de MIA-Generation Architect.

Mode silencieux MIA-Generat ion Developer peut être exécuté en mode silencieux (sans aucune interface graphique). La génération de code peut donc être rendue totalement transparente pour l'utilisateur final.

Dans ce mode, tous les paramètres nécessaires à la génération seront passés en ligne de commande (projet à charger, scénario à générer, etc.).

Voir le chapitre Ligne de commande pour plus de détails sur l'utilisation de MIA-Generat ion Developer en mode silencieux.



Module Analysis

Présentation

Le module Analysis offre aux développeurs et aux chefs de projets des mécanismes pour faciliter le pilotage du processus de génération de code. En remontant des informations sur les fichiers générés et des alertes sur des problèmes détectés, ce module permet de mieux maîtriser les différentes itérations de génération et de mesurer les impacts d'une génération de code à l'échelle du projet.

MIA-Generation – Manuel Utilisateur - Module Analysis 154


Statut des fichiers générés

Le module Analysis permet d’obtenir des informations plus fines sur le statut des fichiers générés.

Ainsi, dans la fenêtre de résultat de la génération, à chaque fichier généré est associée une icône pour indiquer les informations complémentaires suivantes :

Icône Statut

Fichier nouveau (non produit par la génération précédente).

Fichier nouveau (non produit par la génération précédente) contenant au moins une portion entre balises (code manuel).

Fichier dont toutes les portions générées sont identiques par rapport à la génération précédente.

Fichier dont toutes les portions générées sont identiques par rapport à la génération précédente. Fichier contenant au moins une portion entre balises (code manuel).

Fichier dont toutes les portions générées sont identiques par rapport à la génération précédente. Fichier contenant au moins une portion entre balises (code manuel) enrichie par l'utilisateur.

Fichier dont au moins une des portions générées est différente par rapport à la génération précédente.

Fichier dont au moins une des portions générées est différente par rapport à la génération précédente. Fichier contenant au moins une portion entre balises (code manuel).

Fichier dont au moins une des portions générées est différente par rapport à la génération précédente. Fichier contenant au moins une portion entre balises (code manuel) enrichie par l'utilisateur.

Remarque : le statut des fichiers est calculé en se basant sur le répertoire source, le répertoire où se trouvent les fichiers dont on doit extraire les portions de code manuel.



Portions de code Le module Analysis permet de visualiser facilement pour chaque fichier généré les différentes portions : code généré, balises, code manuel, grâce à une couleur de fond différente dans l'éditeur.

Figure 123 : Visualisation des portions dans l'éditeur

Les différentes portions sont représentées dans le navigateur sous chaque nœud résultat. Pour chaque portion, le type (code manuel ou code généré) et les numéros des lignes de début et de fin sont indiqués. En cliquant sur une portion, celle-ci est mise en évidence dans l'éditeur par un encadré rouge.



Figure 124 : Mise en évidence d'une portion

A chaque portion est associée une icône pour indiquer les informations complémentaires suivantes :

Icône Statut

Portion de code généré dans un fichier nouveau.

Portion de code généré identique par rapport à la génération précédente.

Portion de code généré différente par rapport à la génération précédente.

Portion de code manuel dans un fichier nouveau.

Portion de code manuel non enrichie par l'utilisateur.

Portion de code manuel enrichie par l'utilisateur.

Pour les portions de code généré différentes et les portions de code manuel enrichies par l'utilisateur, un onglet supplémentaire apparaît dans l'éditeur pour présenter les différences dans un comparateur.



Figure 125 : Comparateur de portion

En haut à droite, des boutons représentés par des flèches permettent de naviguer dans la portion, de différence en différence.

Pour une portion de code généré, le comparateur indique les différences apparues depuis la dernière génération.

Pour une portion de code manuel, le comparateur indique les différences entre le code manuel généré par défaut et le code manuel saisi par l'utilisateur.

Les portions de code manuel sont conservées dans le fichier <MIA-Generation>\log\tags_history.log. Si ce fichier existait déjà, il est renommé en "tags_history.log.bak", ce qui permet de retrouver facilement l'intégralité du code utilisateur conservé par la génération précédente.

Les portions de code perdues lors d'une nouvelle génération (par exemple quand un objet du modèle n'existe plus, quand il a été renommé, quand des balises sont supprimées du générateur, etc...) ainsi que la liste des fichiers non regénérés sont stockées dans le fichier <MIA-Generation>\log\tags_report.log jusqu'à la prochaine génération.



Alertes

Le module Analysis lève des alertes lorsque certains problèmes sont détectés au moment de la génération. L'icône associée au fichier généré est dans ce cas enrichie de la façon suivante :

Sans alerte Avec alerte

De même, l'icône associée aux portions générées peut être enrichi de la même façon s'il y a lieu :

Sans alerte Avec alerte

Pour activer cette option, il est nécessaire de cocher l'option « Warn when lost code detected » dans l’onglet « Analysis » des options de génération.

Figure 126 : Onglet Analysis

Balises non regénérées Lorsqu’un couple de balises encadrant du code utilisateur n’est pas regénéré, une alerte est levée pour informer de la perte potentielle du code manuel présent entre ces balises.

Figure 127 : Balises non regénérées

Cette situation peut se produire dans les trois cas suivants :

Modification du générateur

Entre deux générations, le générateur a pu évoluer et des balises être modifiées ou supprimées. Dans ce cas, lors d’une regénération le texte des balises précédemment générées n’est plus retrouvé dans les nouveaux fichiers.



Modification du modèle

Entre deux générations, le modèle a pu évoluer. Si le texte de certaines balises est généré à partir de caractéristiques d’objets qui ont changé (par exemple le nom) ces balises sont générées différemment et Mia-Generation ne les retrouvera pas dans les nouveaux fichiers (c'est le cas de la Figure 127 : Balises non regénérées). De la même façon, si certaines balises sont générées à partir d’objets qui ont été supprimés (par exemple la méthode d’une classe) ces balises ne seront également pas regénérées.

Modification des fichiers du répertoire source

Entre deux générations, l'utilisateur a pu modifier manuellement les fichiers et supprimer ou renommer des balises volontairement ou par inadvertance. Si ce type de modification n'est pas remonté dans le générateur et/ou le modèle, alors dans ce cas, les balises seront regénérées mais avec le code manuel généré par défaut, le code manuel enrichi par l'utilisateur sera donc perdu.

Pour ces cas, un icône enrichie apparaît sur chaque fichier généré pour lequel des balises n’ont pas été retrouvées. Sous chacun de ces fichiers, la liste des balises non retrouvées est accessible et pour chacune sont indiquées :

Le texte de la balise de début

Le texte de la balise de fin

Le texte entre les deux balises

Figure 128 : Code manuel perdu

Anomalie suspecte La pertinence de ce type d'anomalie reste à l'appréciation de l'utilisateur. Ces anomalies surviennent dans les cas suivants :

Modification manuelle des fichiers générés

Entre deux générations, pour des raisons de mise au point par exemple, le code généré peut avoir été modifié manuellement même en dehors de balises réservées à cet effet. Lors de la génération suivante, si cette modification manuelle n'a pas été remontée à l'identique dans le générateur et/ou le modèle, une alerte est levée.

Incohérence entre fichiers générés et version du générateur et/ou du modèle



En cas de travail collaboratif, cette cohérence peut facilement être brisée notamment lors d'éventuels échanges de fichiers entre utilisateurs. Des alertes seront levées pour informer des différences suspectes et diminuer ainsi le risque de perte de code, tout en facilitant la maintenance d'un générateur.

Figure 129 : Anomalie suspecte

Fichiers non regénérés D'une génération à la suivante, des modifications du modèle ou du générateur peuvent entraîner la non regénération de certains fichiers. Ces fichiers sont indiqués dans l'onglet Results. La liste de ces fichiers est constituée en fonction du lanceur de génération utilisé.

Figure 130 : Fichiers non regénérés

Remarque : cette option est systématiquement activée avec l'utilisation du module Analysis.



Métriques

Le module Analysis calcule des métriques sur la dernière génération. Ces métriques sont consultables dans l’onglet Trace en édition Architect., dans l'onglet Metrics en édition Developer.

Figure 131 : Statistiques

Figure 132 : tableau de métriques

Pour chaque scénario exécuté, un tableau est affiché avec, pour chaque fichier généré, les métriques suivantes :

Le volume du fichier (en octets)

Le volume des portions de code entre balises (en octets)

Le pourcentage de code généré (calculé sur les volumes en octets)

Le nombre de portions de code entre balises

Le nombre de portions de code manuel enrichies par l'utilisateur

Le temps de génération

Le pourcentage de temps de génération par rapport à l'unité de génération parente

Des métriques consolidées pour le scénario sont affichées sous le tableau.

Le tableau est triable selon 2 clés au choix en cliquant sur les titres de colonnes.

Pour activer cette option, il est nécessaire de cocher l'option « Generate metrics » dans l’onglet « Analysis » des options de génération.



Statistiques de génération

MIA-Generation peut mémoriser des statistiques de génération.

On peut ainsi connaître pour une nœud de trace de génération :

Le temps d'évaluation du script sur l'objet du modèle

Ce même temps d'évaluation par rapport au temps d'évaluation du script appelant (pourcentage)

On peut aussi connaître des statistiques globales à la génération :

Nombre de fois que le script est évalué sur cet objet du modèle

Temps total d'évaluation du script sur cet objet

Temps total d'évaluation du script sur cet objet par rapport au temps total de génération (pourcentage)

MIA-Generation affiche les statistiques locales d'exécution dans l'arbre de la trace de génération. On peut toutefois désactiver cet affichage avec le menu contextuel View > Show statistics.

Activation du module

Le module Analysis est utilisable pour les modules Developer et Architect dès lors qu’une licence correspondante est disponible.

Nom de la licence : MIA_GEN_ANALYSIS

Figure 133 : Activation du module Analysis

MIA-Generation – Manuel Utilisateur - Ligne de commande 163


Ligne de commande

Présentation

MIA-Generation peut prendre en compte différents types de paramètres :

Des paramètres pour sélectionner un projet à utiliser

Des paramètres pour sélectionner un modèle à utiliser

Des paramètres pour gérer le rapport de génération

Des paramètres de transformation

Des paramètres pour surcharger des options utilisateurs

Des paramètres à placer dans le contexte de génération (variable context)

Tous les paramètres lus en ligne de commande ont le format suivant :

-<clé> <valeur>

La clé est précédée du caractère '-', et un espace sépare la clé de la valeur.



Sélection d'un projet

Mode graphique MIA-Generation vous permet de précharger un projet dans votre environnement de génération.

Voici les paramètres que vous pouvez utiliser en ligne de commande :

PARAMETRE DESCRIPTION

project <nomDeFichier> Fichier contenant le projet à précharger

scenarios <nomDeScenario> Nom du scénario à sélectionner dans l'interface graphique.

models <nomDeFichier> Fichier contenant un modèle

format <nomDeFormat> Ce paramètre indique quel format d'import utiliser si on veut précharger un modèle.

Exemples : MIAGeneration.exe -project c:\mia\myProject.prj -models "C:\mia\myModel.xmi" -scenarios "Java Generation" MIAGeneration.exe -models c:\mia\myModel.xmi -format "XMI (XMI)"

Vous pouvez aussi mettre ces paramètres dans un fichier de configuration (un fichier Properties Java), et activer ce fichier en passant en ligne de commande "-silentFile <nomDuFichier>".

Exemple : MIAGeneration.exe -silentFile c:\mia\myConfigFile.ini

Avec le fichier de configuration :

project = c:\\mia\\myProject.prj scenarios = Java Generation models = c:\\mia\\myModel.xmi format = XMI (XMI)

Note : dans un fichier Properties Java, les caractères '\' doivent être doublés.



Mode silencieux

MIA-Generation Developer

MIA-Generat ion Developer peut être lancé en mode silencieux (sans interface graphique). Pour cela, vous devrez passer "-silent true" en ligne de commande.

Si un erreur de ligne de commande est détectée en mode silencieux, cette erreur est affichée dans le fichier "<MIA-Generation>\log\out.log", avec une description de la liste des paramètres attendus.

Voici les paramètres que vous pouvez utiliser en ligne de commande :


project <nomDeFichier> Fichier contenant le projet de génération à utiliser. (obligatoire)

scenarios <nomsDeScenarios> Liste des noms de scénarios à générer. Si ce paramètres n'est pas précisé, on génère chaque scénario public. (optionnel)

models <nomsDeFichiers> Liste de fichiers contenant des modèles qui serviront à la génération. Chaque scénario sera généré sur le modèle du projet chargé et sur chaque modèle de cette liste. (obligatoire)

format <nomDeFormat> Ce paramètre indique quel format d'import utiliser pour charger des modèles autres que celui du projet.

launcher <nomDeFichier> Fichier contenant le launcher à utiliser. Ce paramètre exclut l'utilisation des paramètres précédents.

Exemples : MIAGeneration.exe -silent true -project c:\mia\myProject.prj -models "c:\mia\myModel.xmi;c:\mia\secondModel.xmi" -format "XMI (XMI)"

Ou MIAGeneration.exe -silent true -project c:\mia\myProject.prj -models "c:\mia\myModel.xmi;c:\mia\secondModel.xmi" -format "XMI (XMI)"

De même que pour les paramètres du mode graphique, vous pouvez utiliser un fichier de configuration contenant tous les paramètres nécessaires.

Exemple : MIAGeneration.exe -silent true -silentFile c:\myConfigFile.ini

Avec le fichier de configuration :

project = c:\\mia\\myProject.prj scenarios = Java Generation;Ada Generation models = c:\\mia\\myModel.xmi;c:\mia\secondModel.xmi format = XMI (XMI)

Note : dans un fichier Properties Java, les caractères '\' doivent être doublés.



MIA-Generation Architect

MIA-Generation Architect peut être lancé en mode silencieux (sans interface graphique), en passant aussi "-silent true" en ligne de commande. Ce mode permet, non pas de lancer une génération, mais d’effectuer des actions de manipulation de projet.

Si un erreur de ligne de commande est détectée en mode silencieux, cette erreur est affichée dans le fichier "<MIA-Generation>\log\out.log", avec une description de la liste des paramètres attendus.

Voici le paramètre attendu pour effectuer une telle action :


silentAction <nomAction> Ce paramètre désigne l’action unitaire à effectuer

Les actions disponibles sont les suivantes :

STAND_ALONE_FILE_PRODUCTION : production de fichier « stand alone » pour un projet donné. Des paramètres supplémentaires sont nécéssaires :


project <nomDeFichier> Fichier contenant le projet de génération à utiliser. (obligatoire)

standAloneSaveFile <nomDeFichier>

Fichier cible (obligatoire)

Exemple : MIAGeneration.exe -silent true -silentAction STANDALONE_FILE_PRODUCTION -project c:\mia\myProject.prj –standAloneSaveFile c:\mia\myProject.prx

De même que pour les paramètres du mode graphique, vous pouvez utiliser un fichier de configuration contenant tous les paramètres nécessaires.

Exemple : MIAGeneration.exe -silent true -silentFile c:\myConfigFile.ini



Gestion du rapport de génération MIA-Generation (en mode silencieux ou non) vous permet de paramétrer l'utilisation du rapport de génération en ligne de commande :


reportSaveFile<nomDeFichier> Fichier où enregistrer le nouveau rapport de génération (obligatoire si mode silencieux).

reportOpenFile<nomDeFichier> Fichier contenant le rapport de génération de référence à utiliser (optionnel).

reportLabel <nom> Label du nouveau rapport de génération (optionnel).

reportModelLabel <nom> Label du modèle utilisé dans le rapport de génération (optionnel).

reportGeneratorLabel <nom> Label des packages et scénarios utilisés dans le rapport de génération (optionnel).

reportScenario <nom> Nom du scénario à générer après la création du rapport de génération (optionnel).

metricsSaveFile<nomDeFichier> Fichier où enregistrer les métriques de génération au format xml.

Paramètres de transformation MIA-Generation (en mode silencieux ou non) vous permet de paramétrer les éléments de scénario de type transformation en ligne de commande :


Transformation#N.name <nomDeTransformation>

Ce paramètre indique le nom de la transformation pour laquelle on souhaite préciser des paramètres de lancement

Transformation#N.scenario <nomDeScenario>

Nom du scénario de génération intégrant la transformation précédemment nommé

Transformation#N.model <nomDeFichier>

Chemin d’accès au modèle devant subir la transformation ou ‘current’

Transformation#N.format <nomDeFormat>

Ce paramètre indique quel format d'import doit utiliser le transformateur.

Transformation#N.writer <nomDeFormat>

Ce paramètre indique quel format d’export doit utiliser le transformateur.

Transformation#N.reader <nomDeFormat>

Ce paramètre indique quel format d'import utiliser pour charger le modèle résultant de la transformation.

Transformation#N.project <nomDeRépertoire>

Ce paramètre facultatif indique le répertoire dans lequel se trouve le projet de transformation.



Note

: les paramètres de transformations sont indissociables. L’index N permet d’indiquer les paramètres

pour plusieurs transformations.

Exemple : -transformation#1.name myTransformation -transformation#1.scenario "Java Generation"

-transformation#1.model current -transformation#1.format "UML 1.4 – XMI"

-transformation#1.writer "UML 1.4 – XMI 1.1" -transformation#1.reader

"XMI (XMI)" -transformation#1.project C:\projects\

Avec le fichier de configuration : transformation#1.name = myTransformation transformation#1.scenario = Java Generation transformation#1.model = current transformation#1.format = "UML 1.4 – XMI" transformation#1.writer = "UML 1.4 – XMI 1.1" transformation#1.reader = "XMI (XMI)" transformation#1.project = C:\projects\

Une autre possibilité est de préciser un fichier de paramètres :


transformationsParametersFile <nomDeFichier>

Chemin d'accès au fichier XML de paramétrage de la ou des transformations du projet

Exemple : <?xml version="1.0" encoding="UTF-8"?> <parameters>

<scenario name=" Java Generation ">

<transformation name="myTransformation" modelFilename="current" transformationReader="UML 1.4 – XMI" transformationWriter="UML 1.4 – XMI 1.1" generationReader="XMI (XMI)" projectDirectory="C:\projects\"/>

</scenario> </parameters>

Surcharge des préférences utilisateur Le fichier "<MIA-Generation>\bin\resources\MIAGeneration.ini" contient la sauvegarde de toutes les options utilisateurs. Ces options peuvent être changées dans l'interface graphique de l'outil (voir chapitre Préférences). Ces options peuvent être aussi surchargées en ligne de commande, pour la durée d'exécution de MIA-Generation (Cf. Annexe 1).

Exemples :

MiaGeneration.exe -mia.edition Architect -mia.distribution Professional

MIAGeneration.exe -mia.trace.generateTrace true

MIAGeneration.exe -mia.generation.onScreen false -mia.scripts.defaultText.script "some generated text"



Variables du contexte de génération Tous les paramètres lus en ligne de commande sont automatiquement placés dans le contexte de génération (variable context). Vous pouvez ainsi facilement paramétrer votre génération au lancement de MIA-Generation, pour par exemple spécifier le répertoire de génération.

MIA-Generation – Manuel Utilisateur - Préférences 170


Préférences

Présentation Vous pouvez vous-même modifier un certain nombre d'options, et ainsi paramétrer MIA-Generation par rapport à vos propres besoins. La modification de ces options se fait via le menu Window > Preferences ….



Préférences générales

Figure 134 – Préférences générales

Les options disponibles sont :

Sélection du navigateur HTML à utiliser pour afficher l'aide en ligne.

Lancement automatique du Garbage Collector Java avant et après des opérations coûteuse en mémoire, telles que l'import de modèles ou la génération.

Théoriquement Java gère de lui-même la gestion de la mémoire. Cependant, si vous avez des montées en charge trop importante sur votre machine du fait de l'import d'un gros modèle par exemple, il peut être utile de demander à MIA-Generation de lancer le Garbage Collector.

Sauvegarde des chemins des élements constitutifs d’un projet en relatif ou en absolu.

Utilisation du module Analysis

Utilisation du module de Documentation (à venir)



Préférences d'import

Figure 135 – Préférences d'import


Affichage automatique de la console d'import lorsque des erreurs d'imports sont détectées.



Préférences des scripts

Figure 136 – Préférences des scripts


Utilisation ou non du mécanisme de résolution des scripts.

Activation/Désactivation des évaluations simples



Textes par défaut des scripts

Figure 137 – Textes par défaut des scripts

Cet onglet vous permet de spécifier, pour chaque type de script, le texte par défaut qui est affecté au moment de la création du script

Délimiteurs de Scripts

Figure 138 – Délimiteurs par défaut

Par défaut les chaînes de caractères qui délimitent la présence d’une macro au sein d’un script sont les doubles crochets ouvrants et fermants. En fonction du langage généré, il peut être utile de modifier ces marques (accolades, parenthèses, etc.…).



Préférences de transformation

Figure 139 : Préférences de transformation

Cet onglet vous permet de spécifier où se trouve le logiciel Mia-Transformation qui permettra de transformer un modèle au cours d'un scénario de génération. Il vous permet également de spécifier le répertoire où seront écrits les modèles transformés.



Préférences de notification

Figure 140 : Préférences de notification

Lorsqu'une génération est lancée par un launcher, le projet et le modèle peuvent être rechargés de 3 façons différentes :

- systématiquement,

- uniquement si les fichiers constitutifs ont été modifiés,

- uniquement par une action de rechargement manuelle.

Plusieurs utilisateurs peuvent travailler simultanément sur le même projet.

Cet onglet permet à l'utilisateur d'être notifié des éventuelles modifications extérieures survenues sur les différents composants du projet depuis la dernière vérification, qui a lieu à intervalles réguliers dont la durée est paramétrable.

Lorsqu'une ou plusieurs ressources ont été modifiées, la boîte de dialogue suivante s'affiche, permettant à l'utilisateur de réagir. Il peut alors :

- recharger les ressources qui l'intéressent en utilisant l'un des 2 boutons Reload all & close ou Reload,

- prendre connaissance des différences survenues sur les packages modifiés en utilisant le bouton Compare,

- continuer à travailler en précisant éventuellement qu'il ne souhaite pas être notifié de la modification des ressources qui ne l'intéressent pas en utilisant le bouton Close associé éventuellement à la case à cocher Don't notify of further modifications on checked resources.



Figure 141 : Notification de ressources modifiées



Préférences de raccourcis

Figure 142 : Préférences de raccourcis

Cet onglet présente les différents raccourcis clavier présents dans Mia Génération.



Préférences de configuration

Figure 143 : Préférences de licences

Cet onglet présente les différentes configurations disponibles en fonction des licences de Mia Génération en votre possession.

Sélectionnez une configuration parmi celles proposées, puis cliquez sur OK. Le message suivant apparaît:

Figure 144 : Switch configuration

En cliquant sur 'Oui', Mia-Generation redémarre immédiatement en prenant en compte la nouvelle configuration choisie. En cliquant sur 'Non', Mia-Generation prendra en compte la nouvelle configuration lors du prochain démarrage.

Une licence pour l'édition Architect permet de lancer l'outil en configuration Architect et en configuration Developer.



Une licence pour la distribution Enterprise permet de lancer l'outil en configuration Enterprise et en configuration Professional.

On peut donc en déduire le tableau suivant :

Licence disponible =>

Configuration demandée

V

Architect Enterprise

Architect Professional

Developer Enterprise

Developer Professional

Architect Enterprise Ok Ko Ko Ko

Architect Professional Ok Ok Ko Ko

Developer Enterprise Ok Ko Ok Ko

Developer Professional Ok Ok Ok Ok

MIA-Generation – Manuel Utilisateur - Environnement 181


Environnement

Présentation Ce chapitre présente l'organisation des répertoires de MIA-Generation et de ses méta-modèles.

MIA-Generation

Répertoire bin Ce répertoire contient les exécutables qui vous permettent de lancer MIA-Generation Architect et MIA-Generation Developer.

Répertoire compiler

Contient le compilateur Eclipse JDT (www.eclipse.org) permettant de compiler les scripts de génération.

Répertoire lib

Ce répertoire contient les classes Java nécessaires à l'exécution de MIA-Generation.

Répertoire resources

Ce répertoire contient toutes les DTD utilisées par les fichiers XML gérés par MIA-Generation.

Il contient le fichier "MIAGeneration.ini" : c'est là que sont sauvegardées toutes les options utilisateur de MIA-Generation.

Répertoire flexlm C'est dans ce répertoire que se trouve le fichier de licence "mia_redirect.lic" : ce fichier contient le nom du serveur du gestionnaire de licence. Si vous utilisez une licence fixe, copiez le fichier fourni par le support dans ce répertoire. Ce répertoire contient également l'utilitaire FLEXlm lmtools.exe permettant d'obtenir les informations nécessaires à la création d'une licence.

Répertoire examples Contient des générateurs et modèles d'exemple.

http://www.eclipse.org

MIA-Generation – Manuel Utilisateur - Environnement 182


Répertoire generation C'est le répertoire par défaut de génération : c'est là que seront générés les fichiers qui ne déclarent pas de chemin absolu.

Ce répertoire de génération par défaut peut être modifié dans les options de MIA-Generation.

Répertoire help Ce répertoire contient les fichiers d'aide de MIA-Generation, au format PDF et CHM.

Répertoire log Ce répertoire contient tous les fichiers de log de MIA-Generation. C'est dans ces fichiers que sont sauvegardées toutes les consoles.

Ainsi le fichier "generation.log" contient tout ce qui a été affichée dans la console de génération.

Répertoire plugins Ce répertoire contient le fichier "plugins.cfg" indiquant les plugins à charger au démarrage de MIA-Generation. C'est aussi le répertoire préconisé pour stocker les différents plugins.

Répertoire tools/lib Ce répertoire est destiné à recevoir les composants Java (.class et .jar) de l’utilisateur. Les fichiers JAR et CLASS présents dans ce répertoire sont ajoutés au classpath de MIA-Generation à l’exécution et ainsi accessibles dans les scripts.

Méta-modèles Le répertoire "metamodels" de MIA-Generation contient tous les méta-modèles disponibles.

Chaque sous-répertoire contient les données relatives à un méta-modèle.

Chaque répertoire de méta-modèle contient :

Un fichier JAR avec toutes les classes Java nécessaires à l'utilisation de ce méta-modèle.

Des fichiers de configuration contenant toutes les propriétés relatives à ce méta-modèle (dernier modèle importé, dernier format de modèle utilisé, etc).

Un sous-répertoire "generated", qui contient tous les scripts de génération compilés.

Un sous-répertoire "help", qui contient l'aide relative à ce méta-modèle.

Un sous-répertoire "connectors" : c'est là que se trouvent des imports de modèles personnalisés et les éventuels fichiers de configuration d'import.

MIA-Generation – Manuel Utilisateur - Annexe 1 183


Annexe 1

Options utilisateur Voici la liste des options utilisateur surchargeables en ligne de commande.

Module Analysis Valeurs Désignation

mia.analysis.generateMetrics true | false Calculer les métriques de génération mia.analysis.useModule true | false Utiliser le module Analysis mia.generation.watchtags true | false Alerter en cas d'erreur liée à la gestion du code

manuel mia.analysis.generatedCodeColor

0xXXXXXX Couleur du code généré mia.analysis.manualCodeColor 0xXXXXXX Couleur du code manuel mia.analysis.tagsColor 0xXXXXXX Couleur des balises

Model Browser

Options d'affichage des éléments de modèle dans le model browser. Valeurs Désignation

mia.browser.showEmptyLinks true | false Montrer les liens vides mia.browser.showEmptyMetas true | false Montrer les méta-objets vides mia.browser.showInstancesMeta true | false Indiquer la méta-classe des méta-objets mia.browser.showModelPackages

true | false Répartir les méta-classes selon leur package de définition au sein du méta-modèle

mia.browser.sortInstances true | false Trier les instances de méta-objets

Resultats de generation Valeurs Désignation

mia.buildResults.viewKind

File name | Relative Path | Full Path

Type d'affichage des résultats de génération

Configuration Valeurs Désignation

mia.distribution Enterprise | Professional Indiquer la distribution à utiliser mia.edition Architect | Developer Indiquer l'édition à utiliser mia.evaluation true | false Indiquer quel type de licence utiliser



Options générales Valeurs Désignation

mia.import.model.directory Nom de répertoire Répertoire du dernier modèle ouvert mia.import.model.format XMI (XMI) |

UML21 - XMI (*.uml) | …

Dernier connecteur utilisé

mia.garbageCollector true | false Utiliser le garbage collector pour les opérations coûteuses

mia.general.htmlViewer Programme Navigateur à utiliser mia.general.textEditor Programme Editeur de texte à utiliser mia.general.useDefaultEditor true | false Utiliser le navigateur et l'éditeur de texte

définis par défaut dans l'OS. mia.generation.showWhitespaces

true | false Montrer les espaces, tabulations et sauts de ligne

mia.generation.metricsReportFile Nom de fichier Fichier à utiliser lorsque les métriques sont générées (format xml)

mia.generation.tagsHistoryFile Nom de fichier Fichier utilisé pour sauvegarder les portions de code manuel (format xml)

mia.generation.tagsReportFile Nom de fichier Fichier indiquant les portions de code manuel perdues lors de la dernière génération (format xml)

mia.project.directory Nom de répertoire Répertoire du dernier projet ouvert mia.project.metamodel UML-MIA | UML2 |

UML21 | … Dernier méta-modèle utilisé. Méta-modèle utilisé par défaut lors de la création d'un nouveau projet

mia.project.useRelativeFiles true | false Utiliser des chemins relatifs dans les *.prj

Options de génération Valeurs Désignation

mia.generation.clearContext true | false Effacer le contexte avant de générer

mia.generation.clearContextAfter true | false Effacer le contexte après avoir généré

mia.generation.directory Nom de répertoire Répertoire accueillant les résultats de génération

mia.generation.generateAllBeforeWriting true | false Générer tous les fichiers avant de les écrire

mia.generation.generateReport true | false Générer un rapport mia.generation.handCodedFragments.directory

Nom de répertoire Répertoire où trouver le code manuel à injecter dans les résultats de génération

mia.generation.lineSeparatorKind System default | Windows | Linux/Unix/Solaris |

Mac | OS/2

Séparateur de fin de ligne

mia.generation.onScreen true | false Générer à l'écran mia.generation.overwriteFilesWhenModified true | false Ecraser les fichiers résultats

uniquement lorsqu'ils sonr différents de la génération précédente

mia.generation.useSingleEvaluation true | false Utiliser la fonctionnalité Single Evaluation

mia.trace.generateTrace true | false Lancer la génération avec les traces

mia.trace.useBreakPoints true | false Utiliser les points d'arrêt (valide uniquement si les traces dont



générées) Les paramètres d'un launcher sont prioritaires.

Options de synchronisation Valeurs Désignation

mia.generation.reloadModelAfter true | false Recharger le modèle à la fin de la génération

mia.generation.reloadModelBeforeEachGeneration true | false Recharger le modèle avant chaque génération

mia.generation.reloadModelBeforeIfModified true | false Recharger le modèle avant la génération s'il est modifié

mia.generation.reloadModelOnlyOnUserDemand true | false Ne recharger le modèle que sur action explicite de l'utilisateur

mia.generation.reloadProjectBeforeEachGeneration

true | false Recharger le projet avant chaque génération

mia.generation.reloadProjectBeforeIfModified true | false Recharger le projet avant la génération s'il est modifié

mia.generation.reloadProjectOnlyOnUserDemand true | false Ne recharger le projet que sur action explicite de l'utilisateur

mia.notification.activate true | false Utiliser la notification de modification concurrente

mia.notification.delay Integer Délai de notification

Options de rapport de génération Valeurs Désignation

mia.report.generatorLabel Label du générateur mia.report.label Label du rapport mia.report.modelLabel Label du modèle mia.report.reference name Nom du rapport de référence mia.report.selectReport true | false

Options des scripts

Chaînes de caractères utilisées par défaut lors de la création d'un script et lors d'un appel de script depuis un template.

Valeurs par défaut mia.scripts.defaultText.beginTag // Start of user code mia.scripts.defaultText.endTag // End of user code mia.scripts.defaultText.filename result.txt mia.scripts.defaultText.macro return null; mia.scripts.defaultText.macroService

return current; mia.scripts.defaultText.precondition return Boolean.TRUE; mia.scripts.defaultText.script generated text mia.scripts.delimiters.end ]] mia.scripts.delimiters.start [[

Options de transformation Valeurs Désignation

mia.transformation.outputDirectory Nom de repertoire Répertoire des résultats de transformation

mia-generation -manuel de l'utilisateur · mia-generation – manuel utilisateur - 3 liste des...

Documents