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(a)list.nuiton.org ou eugene-users(a)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(a)list.nuiton.org ou eugene-users(a)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?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
