Index: lutingenerator/doc/ObjectModel.zuml Index: lutingenerator/doc/DevUIDoc.rst diff -u lutingenerator/doc/DevUIDoc.rst:1.1 lutingenerator/doc/DevUIDoc.rst:1.2 --- lutingenerator/doc/DevUIDoc.rst:1.1 Wed Sep 22 13:33:10 2004 +++ lutingenerator/doc/DevUIDoc.rst Tue Apr 4 14:26:28 2006 @@ -1,6 +1,14 @@ -========================= -Documentation Développeur -========================= +======= +UIModel +======= + +:Authors: Aurelie MAZELIER +:Revision: $Revision: 1.2 $ +:Date: $Date: 2006/04/04 14:26:28 $ + + +.. contents:: + Model UIModel ============= @@ -8,59 +16,62 @@ En parcourant un fichier xml, il est possible de construire un objet UIModel. Cet objet est défini par les interfaces suivantes. + Interfaces ---------- - UIModel : - - version XML - - root de type UIModelObject - - le nom du package - - liste des objets du model + - version XML + - root de type UIModelObject + - le nom du package + - liste des objets du model - UIModelObject : - - nom - - type - - un UIModelObject parent - - un UIModel - - une liste d'arguments - - une liste de propriétés - - une liste d'évènements - - une liste d'enfants + - nom + - type + - un UIModelObject parent + - un UIModel + - une liste d'arguments + - une liste de propriétés + - une liste d'évènements + - une liste d'enfants - UIModelArgument : - - une liste d'arguments + - une liste d'arguments - UIModelProperty : - - un nom - - une valeur (de différents type : int, float ...) - - un index + - un nom + - une valeur (de différents type : int, float ...) + - un index - UIModelEvent : - - le nom de la addListenerMethod - - le nom de la listenerInterface - - le nom de la listenerMethod - - le nom du handler - - le nom de la eventProperty + - le nom de la addListenerMethod + - le nom de la listenerInterface + - le nom de la listenerMethod + - le nom du handler + - le nom de la eventProperty - UIModelChild : - - un enfant UIModelObject - - la contrainte de l'enfant de type UIModelConstraint + - un enfant UIModelObject + - la contrainte de l'enfant de type UIModelConstraint - UIModelConstraint : - - une valeur de type Object ou String + - une valeur de type Object ou String + Implantations ------------- Il existe deux implantations de ces interfaces. + impl ~~~~ @@ -68,13 +79,14 @@ du parcours du fichier xml de type uimodel par le parser XMLParser. + xml ~~~ Cette deuxième implantation permet d'obtenir un UIModel lors du parcours du fichier xml de type javaxml par le parser JavaXMLParser. - + JavaXMLParser ------------- @@ -82,6 +94,7 @@ Ce parser permet de parcourir des fichiers javaxml afin d'obtenir un objet UIModel. Ce parser utilise dom4j. + Générateurs =========== Index: lutingenerator/doc/ObjectModel.rst diff -u /dev/null lutingenerator/doc/ObjectModel.rst:1.1 --- /dev/null Tue Apr 4 14:26:33 2006 +++ lutingenerator/doc/ObjectModel.rst Tue Apr 4 14:26:28 2006 @@ -0,0 +1,85 @@ +=========== +ObjectModel +=========== + +:Authors: Arnaud THIMEL +:Contact: thimel@codelutin.com +:Revision: $Revision$ +:Date: $Date$ + + +.. contents:: + + +Introduction +============ + +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. + + +Epuration du modèle XMI +======================= + +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. + +LutinGenerator propose une tranformation XSLT permettant ainsi d'obtenir un XML +épuré décrivant le modèle et ne conservant que l'essentiel des informations. + +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 : + +.. image:: images/Hotel.png + +On obtient un ObjectModel tel que : + +.. image:: images/Hotel.objectmodel.png + + +Modèle mémoire +============== + +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 instancé est basé sur le diagramme de classes suivant : + +.. image:: images/ObjectModel.png + + +Application des templates +========================= + +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 décrire le code qui va être généré. + +Les templates peuvent être de toutes sortes car ils 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, ils peuvent indifféremment générer +du code Java / XML ou encore tout autre type de code (texte ou autre...). Index: lutingenerator/doc/LutinGenerator.rst diff -u /dev/null lutingenerator/doc/LutinGenerator.rst:1.1 --- /dev/null Tue Apr 4 14:26:34 2006 +++ lutingenerator/doc/LutinGenerator.rst Tue Apr 4 14:26:28 2006 @@ -0,0 +1,57 @@ +============== +LutinGenerator +============== + +:Authors: Arnaud THIMEL +:Contact: thimel@codelutin.com +:Revision: $Revision$ +:Date: $Date$ + + +.. contents:: + + +Origine du projet +================= + +LutinGenerator est né à la suite d'une recherche de générateur de code basé sur +un modèle mémoire simple qui s'est terminée par un échec. + +Les projets alors étudiés étaient alors entre autres : + +- Jostraca ; +- EMF ; +- ... + +Le choix de la génération de code par rapport à l'introspection a été fait car +la génération code permet de passer par l'étape compilation et donc de +validation du code généré. En effet, si le besoin était initialement porté sur +de la génération de code Java, LutinGenerator a été pensé pour générer tout type +de code. + + +Côté technique +============== + +LutinGenerator permet l'utilisation d'un ensemble de générateurs. Ces +générateurs sont abstraits de toute spécificité permettant ainsi de les adapter +en fonction des besoins. + +Par défaut, LutinGenerator propose deux implantations de ces générateurs : + +- ObjectModelGenerator (génération à partir d'un modèle objet) ; +- UIModelGenerator (génération à partir d'un modèle graphique). + +Chacun de ses modèle a ses propres spécificités liés à sa structure et son mode +de fonctionnement... + +Cependant, ces générateurs sont inutiles sans des templates de génération. Les +templates sont les fichiers qui vont permettre de déterminer quel sera le +contenu généré en fonction du modèle initial. Grâce à LutinProcessor_, ces +templates sont écrit avec une sytaxe proche de la syntaxe JSP en imbriquant les +portions de code Java avec les portions de code généré. Le rôle de +LutinProcessor est de transformer ces templates en remplaçant la syntaxe JSP par +la syntaxe Java correpondante. Les classes Java obtenues peuvent donc être +compilées et deviennent autonomes. + +.. _LutinProcessor: http://lutinprocessor.labs.libre-entreprise.org/