Logiciel : Sortie de Acceleo 1.1
Posté par Etienne Juliot (page perso, ). Modéré le 11 septembre 2006.
Les principales améliorations apportées par cette version sont :
- Compatibilité avec Eclipse 3.2
- Compatibilité avec GNU/Linux
- Amélioration des performances
- Meilleure compatibilité avec les modeleurs UML et GMF
- Nouveaux services
- Corrections de bugs
![[fr]](../images/fr.png)
Site du projet (489 hits)-
Téléchargement (71 hits)
-
Nouveautés (58 hits)
-
Copies d'écrans (392 hits)
-
Dépêche DLFP pour sortie de la 1.0 (définitions) (46 hits)
> Lire la dépêche (15 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #753129.
Run by 
Cette page a été générée par Templeet en 0.0588s (dont 0.005 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
moi pas comprendre
son intégration dans des vrais projets industriels.
C'est quoi un vrai projet industriel ?
[^]Re: moi pas comprendre
chut, c'est pour les décideurs pressés qui passent par ici... ;-)
[^]générateur de code source?
On va enfin pouvoir reprogrammer tous les logiciels qui font défaut sous Linux en trois cliques de souris à partir des screenshots windows?
J'ai bon?
[^]Re: moi pas comprendre
faut plutôt demander des exemples concrets.
[^]Re: moi pas comprendre
Un vrai projet industriel, c'est un projet autre que le "helloworld" classique.
En gros, c'est un projet qui dure plusieurs mois / années, avec plusieurs développeurs en parallèle.
C'est souvent le problème de la génération de code qui marche bien au début, mais qui, une fois une grosse équipe mis au quotidien dessus, peut poser des problèmes.
Avec Acceleo, on est parti de ces problèmes et on a tenté de les résoudre en y réfléchissant dès le début de son développement. Ca donne par exemple la génération incrémentale (génération, regénération, reregénération), l'intégration dans Eclipse, les chains, ...
[^]Re: moi pas comprendre
Cela dit tous les livres que j'ai lu sur le sujet était très typiques (académique) et sur des thèmes bien maîtrisés: DAB, commerce, gestion de stock ... Qu'est ce qui prouve que ces méthodes sont applicables en générale, sur un projet jamais exploré ou mal maîtrisé? Je voudrai voir des comptes rendus d'utilisation sur de vrai projet industriel divers et variés.[^]Re: moi pas comprendre
A première vue : le thème est moins bien maîtrisé que dans les exemples académiques, donc il y a peut être besoin de souplesse pour faire des changements en cas de modélisation foireuse (les cours de GL que j'ai suivi insistaient tous sur une bonne modélisation à la base sous peine de devoir jeter du code, voire de tout redémarrer, en cas de mauvaise direction). Peut être que ce genre d'outil apporte un peu plus de souplesse en cas de foirage? Le risque que j'y vois : on met moins de soin à la modélisation et à la définition des besoins et on se plante quand même ...
note sur les sujets de tes cours de GL : ca doit recouvrir une partie non négligeable des développements en entreprise, donc si les méthodes marchent pour ça, c'est déja pas mal ;)
[^]Re: moi pas comprendre
En effet, les cours font souvent l'impasse sur la partie évolution.
Entre le début d'un projet et sa fin, la facon de modéliser et surtout l'architecture technique changent.
Les changements sont souvent dû à des imprécisions, des lourdeurs (le syndrômes des "fameux" modèles trop techniques qui ne servent quasiment à rien), des changements de versions de frameworks, ou à des retours des tests de performances / qualité.
Acceleo permet justement plus de souplesse pour prendre en compte ces changements et pour ré-impacter ce qui a déjà été fait. Notamment, la possibilité de modifier facilement la manière de modifier ce qu'il génère rend la mise à jour des générateurs relativement simple.
Pour revenir aux cours, c'est notamment pendant des conférences d'externes que tu peux avoir ce genre de retours. Normal, les profs maîtrise le côté théorique, mais ils n'ont pas forcément le retour d'expérience d'une utilisation sur le terrain.