* Eclipse avec EMF
* Les modeleurs UML2 de Topcased et du projet MDT
* EMF compare qui permet de comparer/fusionner n'importe quel type de modèle (fonctionne aussi avec CVS et Subversion)
* Le support Subversion
* GMF qui permet de faire son propre modeleur.
* Le support OCL, de validation et de transaction d'EMF
* Acceleo avec les générateurs JEE, CSharp, Python, Php et Java
* Mylyn qui apporte l'intégration des bugzilla, trac et autres outils directement dans Eclipse
* Birt qui permet l'édition de rapports
PSM peut sembler ambigüe, je considère qu'il s'agit d'un modèle très proche du code , par exemple le modèle d'analyse définit un objet métier (une classe), pour cette classe abstraite le PSM en possèdera une douzaine d'autres : l'interface, la classe d'implémentation, le DAO qui va bien, etc etc etc.
Un PSM de ce type là n'a, selon moi, pas d'intérêt.
Cependant il me semble intéressant de paramétrer la génération (par le biais d'un modèle - que l'on peut aussi appeler PSM car il est spécifique à la plateforme technique mais généralement on l'appelle PDM) pour dire "génère selon tel ou tel motif de conception" .
Concrètement cela donne
modèle d'analyse + modèle de paramétrage => application générée.
On a donc, non pas une transformation PIM => PSM mais bien un cycle en Y où PIM et PDM permettent de cibler le code.
Cette démarche s'avère beaucoup plus profitable en pratique, un exemple dans Eclipse est l'utilisation des fichiers .ecore et .genmodel, on a bien :
.ecore : modèle d'analyse
.genmodel : modèle de paramétrage
et à partir de ces deux fichier le code Java est généré.
Le PSM peut avoir une utilité, en particulier dans l'informatique embarquée ou il est important de valider ce dernier (les coûts d'un échec n'étant pas les même). Dans l'informatique de gestion ce n'est pas le cas.
[^] # Re: MDA ? Mon c** !
Posté par Cédric Brun . En réponse au journal Generate Early, Generate Often !. Évalué à 3.
* Eclipse avec EMF
* Les modeleurs UML2 de Topcased et du projet MDT
* EMF compare qui permet de comparer/fusionner n'importe quel type de modèle (fonctionne aussi avec CVS et Subversion)
* Le support Subversion
* GMF qui permet de faire son propre modeleur.
* Le support OCL, de validation et de transaction d'EMF
* Acceleo avec les générateurs JEE, CSharp, Python, Php et Java
* Mylyn qui apporte l'intégration des bugzilla, trac et autres outils directement dans Eclipse
* Birt qui permet l'édition de rapports
PSM peut sembler ambigüe, je considère qu'il s'agit d'un modèle très proche du code , par exemple le modèle d'analyse définit un objet métier (une classe), pour cette classe abstraite le PSM en possèdera une douzaine d'autres : l'interface, la classe d'implémentation, le DAO qui va bien, etc etc etc.
Un PSM de ce type là n'a, selon moi, pas d'intérêt.
Cependant il me semble intéressant de paramétrer la génération (par le biais d'un modèle - que l'on peut aussi appeler PSM car il est spécifique à la plateforme technique mais généralement on l'appelle PDM) pour dire "génère selon tel ou tel motif de conception" .
Concrètement cela donne
modèle d'analyse + modèle de paramétrage => application générée.
On a donc, non pas une transformation PIM => PSM mais bien un cycle en Y où PIM et PDM permettent de cibler le code.
Cette démarche s'avère beaucoup plus profitable en pratique, un exemple dans Eclipse est l'utilisation des fichiers .ecore et .genmodel, on a bien :
.ecore : modèle d'analyse
.genmodel : modèle de paramétrage
et à partir de ces deux fichier le code Java est généré.
Le PSM peut avoir une utilité, en particulier dans l'informatique embarquée ou il est important de valider ce dernier (les coûts d'un échec n'étant pas les même). Dans l'informatique de gestion ce n'est pas le cas.