Author: fdesbois Date: 2010-02-18 16:22:44 +0100 (Thu, 18 Feb 2010) New Revision: 816 Added: trunk/src/site/fr/rst/02-objectmodel.rst trunk/src/site/fr/rst/03-generation.rst trunk/src/site/fr/rst/04-templates.rst trunk/src/site/fr/rst/05-execution.rst trunk/src/site/fr/rst/06-fonctionnalites-avancees.rst trunk/src/site/fr/rst/07-glossaire.rst trunk/src/site/fr/rst/08-FAQ.rst trunk/src/site/fr/rst/09-tutoriel-index.rst trunk/src/site/fr/rst/eugene-plan.rst Removed: trunk/eugene/src/site/fr/rst/FAQ.rst trunk/eugene/src/site/fr/rst/ObjectModel.rst Log: add empty files for documentation, reuse old files for FAQ and ObjectModel Deleted: trunk/eugene/src/site/fr/rst/FAQ.rst =================================================================== --- trunk/eugene/src/site/fr/rst/FAQ.rst 2010-02-18 15:06:26 UTC (rev 815) +++ trunk/eugene/src/site/fr/rst/FAQ.rst 2010-02-18 15:22:44 UTC (rev 816) @@ -1,16 +0,0 @@ -=== -FAQ -=== - -Comment convertir les modèles UML de Poseidon vers ArgoUML ? -============================================================ - -Il faut sauver le modèle sous Poseidon en XMI, on bien l'extraire du -fichier .zmul qui est en fait un fichier zip:: - - xlstproc -o <argo-file>.xmi poseidon2argouml.xsl <poseidon-file>.xmi - -Ensuite dans ArgoUML ouvrez le fichier généré. - -Les diagrammes ne sont pas convertie, il faut donc les recréer a partir des -classes en faisant du drag&drop. Deleted: trunk/eugene/src/site/fr/rst/ObjectModel.rst =================================================================== --- trunk/eugene/src/site/fr/rst/ObjectModel.rst 2010-02-18 15:06:26 UTC (rev 815) +++ trunk/eugene/src/site/fr/rst/ObjectModel.rst 2010-02-18 15:22:44 UTC (rev 816) @@ -1,92 +0,0 @@ -=========== -ObjectModel -=========== - -:Authors: Arnaud Thimel, Florian Desbois -:Contact: eugene-devel@list.nuiton.org ou eugene-users@list.nuiton.org -:Revision: $Revision: 650 $ -:Date: $Date: 2009-10-21 15:22:32 +0200 (Wed, 21 Oct 2009) $ - - -.. 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. - -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. - -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 instancié est basé sur le diagramme de classes (méta-modèle) suivant : - -.. image:: ../images/ObjectModel.png - -Les interfaces disponibles pour les générateurs sont les suivantes : - -.. image:: ../images/ObjectModel_Interfaces.png - -ObjectModelGenerator : - -.. image:: ../images/ObjectModel_Generator.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...). Copied: trunk/src/site/fr/rst/02-objectmodel.rst (from rev 815, trunk/eugene/src/site/fr/rst/ObjectModel.rst) =================================================================== --- trunk/src/site/fr/rst/02-objectmodel.rst (rev 0) +++ trunk/src/site/fr/rst/02-objectmodel.rst 2010-02-18 15:22:44 UTC (rev 816) @@ -0,0 +1,92 @@ +=========== +ObjectModel +=========== + +:Authors: Arnaud Thimel, Florian Desbois +:Contact: eugene-devel@list.nuiton.org ou eugene-users@list.nuiton.org +:Revision: $Revision: 650 $ +:Date: $Date: 2009-10-21 15:22:32 +0200 (Wed, 21 Oct 2009) $ + + +.. 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. + +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. + +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 instancié est basé sur le diagramme de classes (méta-modèle) suivant : + +.. image:: ../images/ObjectModel.png + +Les interfaces disponibles pour les générateurs sont les suivantes : + +.. image:: ../images/ObjectModel_Interfaces.png + +ObjectModelGenerator : + +.. image:: ../images/ObjectModel_Generator.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...). Property changes on: trunk/src/site/fr/rst/02-objectmodel.rst ___________________________________________________________________ Added: svn:mergeinfo + /branches/1.0.1-Javabuilder/eugene/src/site/fr/rst/ObjectModel.rst:641-651 /branches/1.1.0-Javabuilder/eugene/src/site/fr/rst/ObjectModel.rst:652-681 /branches/eugene-2.0/eugene/src/site/fr/rst/ObjectModel.rst:682-754 Copied: trunk/src/site/fr/rst/08-FAQ.rst (from rev 815, trunk/eugene/src/site/fr/rst/FAQ.rst) =================================================================== --- trunk/src/site/fr/rst/08-FAQ.rst (rev 0) +++ trunk/src/site/fr/rst/08-FAQ.rst 2010-02-18 15:22:44 UTC (rev 816) @@ -0,0 +1,16 @@ +=== +FAQ +=== + +Comment convertir les modèles UML de Poseidon vers ArgoUML ? +============================================================ + +Il faut sauver le modèle sous Poseidon en XMI, on bien l'extraire du +fichier .zmul qui est en fait un fichier zip:: + + xlstproc -o <argo-file>.xmi poseidon2argouml.xsl <poseidon-file>.xmi + +Ensuite dans ArgoUML ouvrez le fichier généré. + +Les diagrammes ne sont pas convertie, il faut donc les recréer a partir des +classes en faisant du drag&drop. Property changes on: trunk/src/site/fr/rst/08-FAQ.rst ___________________________________________________________________ Added: svn:mergeinfo + /branches/1.0.1-Javabuilder/eugene/src/site/fr/rst/FAQ.rst:641-651 /branches/1.1.0-Javabuilder/eugene/src/site/fr/rst/FAQ.rst:652-681 /branches/eugene-2.0/eugene/src/site/fr/rst/FAQ.rst:682-754 Added: trunk/src/site/fr/rst/eugene-plan.rst =================================================================== --- trunk/src/site/fr/rst/eugene-plan.rst (rev 0) +++ trunk/src/site/fr/rst/eugene-plan.rst 2010-02-18 15:22:44 UTC (rev 816) @@ -0,0 +1,200 @@ +Plan documentation EUGene 2.0 +============================= + +:Authors: jruchaud, fdesbois +:Date: 18 fév. 2010 +:Version: 1.1 + +- Introduction + + * C'est quoi le MDA + * Philosophie d'Eugene + * Comparaison avec les solutions existantes (acceleo) + +- MétaModel: ObjectModel + + * Présentation + * Comparaison EMF/MOF + +- Processus de génération + + * Générateur + * Transformation de modèle + +- Template + + * Syntaxe des générateurs + * Implantation d'une transformation de modèle + * Générateur en Java + +- Build + + * Ant + * Maven + +- Fonctionnalités avancées + + * Writer + * Reader + * Extension + +- Glossaire + +- Tutoriels + + * Tutoriel 1 : Création d'un modèle UML avec résultat ObjectModel + * Tutoriel 2 : Création d'une template de génération (Generator) + * Tutoriel 3 : Création d'un transformer de modèle pour Java (ObjectModel to ObjectModel) + * Tutoriel 4 : Création d'un reader pour charger l'ObjectModel + * Tutoriel 5 : Création d'un transformer pour un autre modèle que l'ObjectModel (ObjectModel to ?) + * Tutoriel 6 : ... + +- FAQ + +Introduction +------------ + +Ressource : jruchaud? + +- Revoir DiscussionSurTypeDeGeneration.rst + +MétaModel : ObjectModel +----------------------- + +Présentation +~~~~~~~~~~~~ + +Ressources : jruchaud?, fdesbois + +- Revoir ObjectModel.rst +- Diagramme de classes vu MetaModel (ObjectModel.png) +- Diagramme de classes réel (implantation) (ObjectModel_interfaces.png) + +Comparaison EMF/MOF +~~~~~~~~~~~~~~~~~~~ + +Ressource : jruchaud? + +Processus de génération +~~~~~~~~~~~~~~~~~~~~~~~ + +Ressource : fdesbois + +- Diagrammes d'activités : processus standard, processus avec transformer, processus java + +Template +-------- + +- Diagramme de classes sur l'héritage entre Template, Generator, Transformer, ... + +Syntaxe des générateurs +~~~~~~~~~~~~~~~~~~~~~~~ + +Ressource : jruchaud? + +- Utilisation de nuiton-processor +- Pattern generateFrom ... + + +Implantation d'une transformation de modèle +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Ressource : fdesbois + +- Entrée du transformer (model) +- Sortie du transformer (template, model) +- Pattern transformFrom +- ObjectModelTransformer +- ObjectModelBuilder + +Générateur en java +~~~~~~~~~~~~~~~~~~ + +Ressource : fdesbois + +- JavaGenerator +- ObjectModelTransformerToJava +- JavaBuilder +- ImportsManager + +Fonctionnalités avancées +------------------------ + +Writer +~~~~~~ + +Ressource : tchemit? + +- Principe de chaînage + +Reader +~~~~~~ + +Ressources : fdesbois, echatellier? + +- Utilisation de digester +- ObjectModelReader / StateModelReader + +Extension +~~~~~~~~~ + +Ressources : tchemit?, fdesbois + +- extension de l'ObjectModel +- extensions pour Java : imports, annotations, constantes, ... + +Build +----- + +Ant +~~~ + +Ressource : echatellier? + +- plugin eclipse ??? + +Maven +~~~~~ + +Ressource : tchemit? + +- Documentation existante : maven-eugene-plugin + +Divers +------ + +Glossaire +~~~~~~~~~ + +Ressources : tout le monde + +- A compléter au fur et à mesure + +FAQ +~~~ + +- Reprendre existant + compléments si besoin + +Tutoriels +~~~~~~~~~ + +- Cas concrets, en attente car très long à produire + +Traduction anglais +~~~~~~~~~~~~~~~~~~ + +Ressource : jcouteau? + + + + + + + + + + + + + +