| authors : | Arnaud Thimel |
|---|---|
| Florian Desbois | |
| contact : | eugene-devel@list.nuiton.org ou eugene-users@list.nuiton.org |
| revision : | 1079 |
| date : | 2011-06-28 11:15:23 +0200 (Tue, 28 Jun 2011) |
Ce document ne considère pas pour le moment les évolutions apportées par la version 2.0 d'EUGene.
TODO : revoir cette documentation
Le générateur ObjectModelGenerator est prévu pour lire et analyser des modèles objets puis générer du code à partir de ceux-ci. En UML, un modèle objet est représenté par un diagramme de classe. Cette vision des modèles objet étant très répandue, elle sert de base à l'ObjectModelGenerator (il est à noter cependant que ce n'est pas obligatoire).
Partons donc du principe que l'on dispose d'un modèle (diagramme de classe) créé à l'aide d'un outil de modélisation au format XMI (XML Metadata Interchange).
La génération de code se fait ensuite en trois étapes :
Epuration du XMI en un code XML ne conservant que les informations utiles ;
Mise en mémoire du modèle simplifié ;
Application des templates / génération de code.
La plupart des outils de modélisation décrivent leur modèle en XMI. Or le XMI est trop verbeux pour être compréhensible aisement.
Eugene propose une tranformation XSLT permettant ainsi d'obtenir un XML épuré décrivant le modèle et ne conservant que l'essentiel des informations.
Ce modèle intermédiaire garantit aussi la stabilité et pérennité d'EUGene, puisque qu'on se base toujours sur les modèles d'EUGene et non pas directement sur les modèles extérieurs (XMI) trop variants d'une version à l'autre.
Si on veut supporter une nouvelle version de XMI par exemple, il convient de définir la feuille de style de transformation adéquate.
Parmi les informations extraites, on peut citer :
Objets (classes, classes abtraites, interfaces)
Attributs (nom, type, visibilité, ...)
Relations entre les classes (toutes multiplicités, navigabilité, classes d'association, ...)
Opérations (nom, type de retour, noms et types des arguments, exceptions levées, ...)
Stéréotypes
A partir du diagramme suivant :
On obtient un ObjectModel tel que :
Une fois le XMI ramené à un XML compréhensible, le modèle est chargé en mémoire afin de subir la génération.
Ainsi, le modèle instancié est basé sur le diagramme de classes (méta-modèle) suivant :
Les interfaces disponibles pour les générateurs sont les suivantes :
ObjectModelGenerator :
Chaque template est à lui seul un générateur qui hérite de ObjectModelGenerator. Toute partie de ce générateur peut donc être surchargée permettant ainsi une forte personnalisation des générateurs. Le rôle de l'ObjectModelGenerator est donc de parcourir le modèle et à chaque élément clé du modèle, (model, classes interfaces, classifier) les méthodes correspondantes sont appelées. Par défaut, ces méthodes décrites dans le générateur de base sont vide, et il n'en ressort donc aucun code généré. Les templates ont donc pour but de surcharger ses méthodes et de décrire le code qui va être généré.
Les templates peuvent être de toutes sortes car elles peuvent générer un fichier différent par modèle, par interface, par classe ou encore par classifier (souche commune aux classes et interfaces). De plus, elles peuvent indifféremment générer du code Java / XML ou encore tout autre type de code (texte ou autre...).
