Que les choses soit claires : il ne s'agit en aucune façon de remplacer l'écriture du code. Le modèle est un outil qui permet de générer la structure du code, les fichiers de configuration, en bref les parties du projet présentant peu d'intérêt, cette génération est complétée par la suite par du code manuel. Acceleo permet justement de garder ce code manuel même après une re-génération.
Pour les gens allergiques à UML, je leur conseille vivement de consulter les démonstration flash utilisant des DSL, par exemple MindMap (http://www.acceleo.org/pages/module-mindmap-vers-html-/ ).
On y utilise un formalisme simpliste : Idée/Contenu de l'idée / relations pour modéliser une carte mentale. Cette dernière est ensuite exploitée pour générer des slides XHTML.
L'approche à plusieurs avantages qui peuvent avoir un intérêt selon les projets (mais pas forcément !). En voici quelques un en vrac :
* la cohérence : si on génère des objets métiers par exemple, on a la garantie qu'ils respectent tous les mêmes règles de nommage, la même structuration. Si l'on doit effectuer un changement dans cette structuration, il suffit de mettre à jour le template et les objets métiers se conformerons alors à la nouvelle règle.
* la capitalisation de bonnes pratiques : imaginons que le projet KDE réalise un module de génération, ce dernier définira toutes les bonnes pratiques d'architectures du projet, ainsi on peut imaginer que le développeur utilisant le générateur modélise une application constituée de plusieurs composants, le module de génération va en faire autant de KParts respectant
* la séparation des préoccupations : le modèle contient les informations fonctionnelles, objets métiers, architecture fonctionnelle, l'architecture technique est définie dans le module de génération.
* la synchronisation entre le modèle, qui documente mais ici, pas seulement, et le code source de l'application. Un nouveau contributeur arrive, il dispose directement d'une vision globale du projet en phase avec le code source.
* un certaine indépendance vis à vis de la plateforme technique: même exemple que précédemment avec KDE, le développeur à un modèle de son application qu'il a générée pour KDE, un jour de grande dépression (ou ayant abusé de je ne sais quel alcool) il décide de baser son application sur Gnome. Il réalise (ou utilise un générateur) pour Gnome et dispose directement d'une application ayant une structuration équivalente à celle de KDE mais qui utilise du CORBA ^^. (on pourrait imaginer le même processus, plus probable, qui permet la mise à jours de KDE3 vers KDE4 par exemple.)
* l'apprentissage : l'utilisation d'un tel module de génération facilite grandement l'apprentissage d'un framework. En effet il est facile d'expérimenter en modifiant le modèle, et en observant le code généré.
Ce type d'approche marche réellement en pratique à partir du moment où l'outil n'ajoute pas de contraintes sur le développeur et que ce dernier y trouve son compte : il modélise 1 objet, cela génère n fichiers rébarbatif à faire manuellement.
EMF (http://www.eclipse.org/emf/) est un projet Eclipse qui permet la méta-modélisation, c'est à dire - de manière succinte - la définition d'un modèle pour définir des modèles. Concrètement cela permet de se passer d'UML, pour utiliser un langage plus réduit ou spécifique au domaine concerné. Par exemple dans le cas du métamodèle de jeu vidéo, la notion de classe, de composants, n'a aucun sens. EMF permet de définir un méta-modèle qui permet de représenter les concepts de "règle du jeu", "évènements", "états" ou encore "déplacements".
[^] # Re: utilité ?
Posté par Cédric Brun . En réponse à la dépêche Acceleo 2.0.0 : génération de code PHP, JEE, Java, CSharp et Python. Évalué à 6.
Pour les gens allergiques à UML, je leur conseille vivement de consulter les démonstration flash utilisant des DSL, par exemple MindMap (http://www.acceleo.org/pages/module-mindmap-vers-html-/ ).
On y utilise un formalisme simpliste : Idée/Contenu de l'idée / relations pour modéliser une carte mentale. Cette dernière est ensuite exploitée pour générer des slides XHTML.
L'approche à plusieurs avantages qui peuvent avoir un intérêt selon les projets (mais pas forcément !). En voici quelques un en vrac :
* la cohérence : si on génère des objets métiers par exemple, on a la garantie qu'ils respectent tous les mêmes règles de nommage, la même structuration. Si l'on doit effectuer un changement dans cette structuration, il suffit de mettre à jour le template et les objets métiers se conformerons alors à la nouvelle règle.
* la capitalisation de bonnes pratiques : imaginons que le projet KDE réalise un module de génération, ce dernier définira toutes les bonnes pratiques d'architectures du projet, ainsi on peut imaginer que le développeur utilisant le générateur modélise une application constituée de plusieurs composants, le module de génération va en faire autant de KParts respectant
* la séparation des préoccupations : le modèle contient les informations fonctionnelles, objets métiers, architecture fonctionnelle, l'architecture technique est définie dans le module de génération.
* la synchronisation entre le modèle, qui documente mais ici, pas seulement, et le code source de l'application. Un nouveau contributeur arrive, il dispose directement d'une vision globale du projet en phase avec le code source.
* un certaine indépendance vis à vis de la plateforme technique: même exemple que précédemment avec KDE, le développeur à un modèle de son application qu'il a générée pour KDE, un jour de grande dépression (ou ayant abusé de je ne sais quel alcool) il décide de baser son application sur Gnome. Il réalise (ou utilise un générateur) pour Gnome et dispose directement d'une application ayant une structuration équivalente à celle de KDE mais qui utilise du CORBA ^^. (on pourrait imaginer le même processus, plus probable, qui permet la mise à jours de KDE3 vers KDE4 par exemple.)
* l'apprentissage : l'utilisation d'un tel module de génération facilite grandement l'apprentissage d'un framework. En effet il est facile d'expérimenter en modifiant le modèle, et en observant le code généré.
Ce type d'approche marche réellement en pratique à partir du moment où l'outil n'ajoute pas de contraintes sur le développeur et que ce dernier y trouve son compte : il modélise 1 objet, cela génère n fichiers rébarbatif à faire manuellement.
EMF (http://www.eclipse.org/emf/) est un projet Eclipse qui permet la méta-modélisation, c'est à dire - de manière succinte - la définition d'un modèle pour définir des modèles. Concrètement cela permet de se passer d'UML, pour utiliser un langage plus réduit ou spécifique au domaine concerné. Par exemple dans le cas du métamodèle de jeu vidéo, la notion de classe, de composants, n'a aucun sens. EMF permet de définir un méta-modèle qui permet de représenter les concepts de "règle du jeu", "évènements", "états" ou encore "déplacements".