ATL 2 marque un tournant dans le projet car il représente le 1er résultat visible des travaux d'industrialisation par une entreprise française (Obeo) des résultats d'un laboratoire de recherche de l'INRIA.
En plus de cette collaboration et de nombreuses nouveautés techniques, ATL 2 est donc maintenant inclus dans le prochain Eclipse 3.4 au sein de Eclipse Modeling Project. ATL sert dans de nombreux cas :
- interopérabilité entre outils
- raffinement (différents niveaux de "zoom" sur un modèle, pour par exemple passer d'une conception générale à une conception détaillée)
- extraction d'information
- traductions de sémantique (par exemple, d'un Profil UML vers un métamodèle dédié)
- refactoring de modèle.
ATL se base sur de nombreux standards tels que XMI, OCL et Ecore, et il a même fait parti des contributions initiales au standard QVT de l'OMG.
Grâce à ce respect des standards, ATL peut s'insérer dans une chaîne d'outils libres et bâtis sur Eclipse : UML2 avec Topcased ou Papyrus, métamodèles avec EMF, modeleurs dédiés avec GMF, génération de code avec Acceleo.
La licence de ATL, comme tous les projets de la fondation Eclipse, est EPL.
Les nouveautés de ATL 2 :
- machine virtuelle (ATL VM) basée nativement sur EMF
- performances (jusqu'à x20 ! )
- complétion dans l'éditeur des règles de transformation
- intégration au système de build Eclipse.org
- installation par updatesite
- stabilisation et correction de bugs.
La collaboration labo / PME est une parfaite illustration de ce qu'essaient de faire les pouvoirs publics demander à des grands industriels d'émettre des besoins de R&D, faire naître des idées par des chercheurs et les laisser faire des prototypes les validant, et enfin proposer à une entreprise d'édition logiciel d'en faire un produit et de porter une offre commerciale viable.
Dans le cas d'ATL, ces travaux ont pris place à travers des projets collaboratifs issus de pôles de compétivité (System@atic à Paris, Aerospace à Toulouse et Images & Réseau à Nantes), notamment grâce au projet Edona financé par la DGE (Direction Générale des Entreprises) qui vise à construire une plateforme de conception de systèmes automobiles.
Obeo, de par son implication déjà très forte dans l'OpenSource (contributions à Acceleo) et dans la fondation Eclipse (8 commiteurs), a ainsi été choisi pour porter à la fois les développements techniques et l'offre de services (formations, support, sur-mesure et conseils) au dessus d'ATL. L'INRIA peut ainsi se recentrer sur ses activités de recherche, et les industriels obtiennent un support professionnel. Cette collaboration montre que le logiciel libre est un vecteur efficace et rentable de distribution d'une technologie innovante.
Historique du projet :
- 1990 : premiers travaux sur la transformation de modèles
- 1998 : publication initiale d'une première proposition dans le cadre d'une thèse à l'Université de Nantes (suivie par Jean Bézivin)
- 2004 : Première mise en œuvre du langage ATL réalisée dans le cadre du projet CARROLL/MOTOR
- 2005 : Projets collaboratifs tels que ModelWare, ModelPlex, Usine Logicielle ou OpenEmbeDD
- 2004 : le projet Eclipse GMT est créé afin d'accueillir en incubation des projets de recherche sur les outils de modélisation
- 2006 : Obeo donne naissance à sa première contribution OpenSource nommée Acceleo
- fin 2006 : ATL est promu technologie à vocation industrielle au sein de Eclipse M2M
- 2007 : Obeo commence les travaux d'industrialisation et lance l'initiative ATL Pro (http://www.atl-pro.com)
- 2008 : sortie d'ATL 2.0.
Aller plus loin
- ATL (51 clics)
- Wiki et docs (12 clics)
- ATL-Pro (24 clics)
- Obeo (14 clics)
- Labo ATLAS (16 clics)
- Téléchargement (19 clics)
# ...
Posté par ciol_banni . Évalué à -10.
[^] # Re: ...
Posté par Bungee Tux . Évalué à -10.
# C'est pas de chance...
Posté par kokotchY . Évalué à 1.
[^] # Re: C'est pas de chance...
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Par contre tes appréciations seraient grandement appréciées :
- Quelles sont les qualités de ATL 1, ses défauts et ceux qui sont corrigés par ATL 2 ?
- Facilité d'utilisation
- Vitesse d'apprentissage.
- ...
[^] # Re: C'est pas de chance...
Posté par kokotchY . Évalué à 4.
Déjà, un chouette point, c'est que ATL peut travailler sur un modèle ecore (disponible dans eclipse), et qu'il existe un outil graphique dans eclipse pour créer ses modèles et méta-modèles en ecore: topcased.
Mon travail était de créer une transformation qui au départ d'une modèle d'architecture hardware ajoutait une couche de sécurité (par l'ajout de composant de sécurité).
Une transformation est décrite par un ensemble de règle de transformation. Ces règles spécifient comment un objet dans le modèle de départ doit être représenté dans le modèle d'arrivé.
Les relations entre les eclasses (objets du modèle, un peu comme les classes dans les diagrammes de classes d'UML) sont préservées automatiquement lors de la transformation et ce n'est pas au concepteur de la transformation de le faire.
Cela permet de simplifier le code énormément puisqu'il suffit de réellement coder la partie "modifiée" du modèle.
Le langage en lui-même est assez "bizarre" au premier abord. On dirait un peu un mélange de différent paradigme de programmation.
Voici un exemple de règle (juste pour donner une idée) :
rule CopyInterfaces {
from
oa: adl!Interface
to
na: adl!Interface (
-- copy the attributes
name <- oa.name
)
}
En ce qui concerne les défauts, il faut d'abord savoir que si le script ATL n'est pas dans un projet ATL, ca ne marchera pas.
Ensuite, les erreurs sont assez peu explicites.
Il paraît qu'il y a un outil de debug intégré, mais je ne l'ai pas trouvé. Et c'est vraiment ce qu'il manquait dans ATL.
Car quand la transformation ne s'exécute pas correctement, il est souvent difficile de savoir d'où vient le problème.
Enfin, je vais un peu regarder cette nouvelle version, on va voir ce qui est vraiment amélioré.
[^] # Re: C'est pas de chance...
Posté par Duncan Idaho . Évalué à 6.
En langage naturel, ça donne quoi ? Ça sert à quoi ?
Sinon, félicitation à toutes les équipes, c'est une belle collaboration !
[^] # Re: C'est pas de chance...
Posté par Bozo_le_clown . Évalué à 3.
On a une transformation qui prend un modèle en entrée (oa ?) décrit par métamodèle et crée un autre modèle en sortie (na ?)
Ici on décrit un règle qui se contente de recopier le concept "Interface" (UML?) d'un modèle à l'autre et qui lui affecte le champ name de l'interface de épart
C'est un langage déclaratif.
Après il y a un runtime qui passe en revue le modèle d'entrée et lui applique toutes les régles définies.
Ca finit par reconstruire un modèle en sortie
Un peu comme le ferait Prolog avec son moteur d'inférence
# OMG
Posté par zerkman (site web personnel) . Évalué à 10.
[^] # Re: OMG
Posté par Clément David (site web personnel) . Évalué à 6.
Heureusement que certains documents explique le trus car sinon c'est vrai que pour un non spécialiste il y a un niveau de différence.
Excellent intro sur le méta-modèle et eclipse en français : [http://www.topcased.org/IMG/pdf/TOPCASED_neptune_2005_A4.pdf]
[^] # Re: OMG
Posté par reno . Évalué à 7.
Sauf que ce ne sont *pas* des noms, ce sont des sigles.
Et la mauvaise habitude d'utiliser des sigles sans les détailler la première fois, c'est franchement désagréable..
[^] # Re: OMG
Posté par Jean B . Évalué à 4.
[^] # Re: OMG
Posté par CrEv (site web personnel) . Évalué à 5.
[^] # Re: OMG
Posté par BAud (site web personnel) . Évalué à 3.
[^] # Re: OMG
Posté par reno . Évalué à 2.
[^] # Re: OMG
Posté par Temsa (site web personnel) . Évalué à 3.
Les sigles expriment souvent quelquechose de complexe et évitent les néologismes à la mort moi le noeud.
Au bout d'un certain temps, il faudrait leur donner un vrai nom par contre... Mais rassurons nous, l'académie française veille, et nous trouve des mots tels que "cédérom" pour remplacer les sigles! Une grande avancée pour l'humanité.
Quelqu'un de familier avec Eclipse aura reconnu la plupart des sigles en sachant ce qu'ils font, mais pas forcément en connaissant leur signification.
Bref d'une manière générale, c'est l'abus de vocabulaire complexe (par rapport au public visé par l'article) qui est a condamner, pas les sigles en particulier.
[^] # Re: OMG
Posté par Wawet76 . Évalué à 1.
# Ca a l'air vachement bien
Posté par Nicolas Delsaux (site web personnel) . Évalué à 10.
Un exemple "dans la vraie vie" c'aurait été mieux.
Parce que pour moi, ces histoires de transformation de modèle, ça sent la masturbation intellectuelle à plein nez.
[^] # Re: Ca a l'air vachement bien
Posté par Ontologia (site web personnel) . Évalué à 3.
Ca ressemble à un chaipaskoi, mais bitable, ce qui est à relever dans le monde universitaire, avec un espèce de SQL pour filtrer les données.
A part ça, si l'auteur de la news pouvait nous expliquer l'apport de tout cela par rapport à un énième méta-truc générateur de code....
Je vais quand même esssayer de creuser....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ca a l'air vachement bien
Posté par Bozo_le_clown . Évalué à 10.
Attention ! victoire au Business Loto garantie
Dans les MDA, MDE, MDSD, ... et consorts, ce qui revient est le modèle qui est placé au coeur du processus de développement d'où le MD (Model Driven)
Déjà il faut voir un intérêt dans la modélisation pour le génie logiciel.
Les modèles permettent de s'abstraire de la complexité des systèmes réels pour n'en retenir que certains aspects qui nous intéressent. Le réel ne pouvant souvent pas être appréhendé dans sa globalité par un être humain.
Les modèles, on en trouve un peu partout. On a les standards: UML pour l'objet, SysML, le BPMN pour les services, .... mais aussi certains outils, métiers ou entreprises ont développé leur propre formalisme. Les projets EMF/GMF d'Eclipse visent d'ailleurs à faciliter la vie de celles-ci. Plutôt que d'utiliser un langage généraliste comme UML qui devient gigantesque et dont seule une partie nous est utile , ils permettent de se fabriquer une notation graphique sur mesure. Mais ils permettent de décrire UML aussi (plugin uml2 au dessu de EMF/GMF). On parlera de DSL (Domain Specific Language). A un certain niveau les langages de programmation eux-même peuvent être perçus en tant que modèles. Tout ca est bien beau mais si j'utilise une notation pour représenter mes écrans d'IHM, que je rajoute un formalisme pour la modélisation des données relationnelles (MCD Merise) , un peu d'UML par ci et encore une notation propriétaire pour la description des mes processus métiers par là. Comment je fais pour vérifier la cohérence de l'ensemble et surtout pour la maintenir lorsque je fais le moindre changement. A la mimine ca décourage un peu.
Et c'est là que l'OMG a sorti sa grande idée. Déjà on a les modèles.
Chaque modèle est décrit par un langage. Et si on décrivait chacun de ces langages de modélisation par un modèle (le metamodèle) en utilisant un seul et même langage de description ? Et voici que le MOF (Meta Object Facility) fait son apparition. Il permet d'unifier tous les langages de modélisation et il s'auto-décrit. (Voir la fameuse pyramide 4 layers qui décrit tout ça - pas trouvé la photo). MOF étant une spec ,Eclipse avait donc besoin de l'implementer pour son projet EMF. Il s'agit d'Ecore (un sous-ensemble de MOF en fait). A partir de là on devient capable de faire des transformations de modèles entre 2 modèles d'un même langage mais aussi entre 2 modèles exprimé avec des formalismes différents puisqu'on maitrise la description de leur métamodèles. On parle de transformation M2M (Model 2 Model). Soyons joueur et décrivons la spec de ce langage de transformation. Nous l'appellerons QVT. ATL c'est une impléméntation de QVT même si elle en a un peu dérivé car QVT trainait un peu.
Reste un problème: Comment à partir d'un modèle peut on arriver à générer du code ? En soi, le code est décrit par un langage qui dispose de sa propre grammaire et donc de son métamodèle.
Toutefois écrire une transformation de M2M en considérant le code comme un modèle n'est pas chose aisée.
On préfère souvent utiliser d'autres techniques comme des langages à base de template décrivant le code généré par un fichier d'exemple qui contient des balises. Elles pointent sur des éléments du métamodèle associé au modèle à partir duquel on génère. Un peu à la manière des JSPs par exemple. On parle alors de langages de transformation M2T (Model 2 Text)
Acceleo par exemple joue dans cette catégorie et c'est pourquoi avec ATL, ils sont souvent complémentaires.
OpenArchitectuware propose les 2 types de langages ainsi que d'autres outils propriétaires comme MIA. Certains préfèrent s'appuyer sur un tooling pour les transfo M2M comme par exemple Rational Software Architect.
Dernière problématique. Passer d'un modèle à un autre n'est pas toujours évident car parfois on souhaite orienter la transformation ou lui rajouter des informations. Par exemple, passer d'un modèle UML d'analyse à un modèle de conception ou d'un modèle de conception à du code. Quitte a faire, ces infos de transfo ca n'est ni plus ni moin qu'un modèle . Appelons le modèle de marquage. Mais comment faire ? Soit on rajoute cette information dans le modèle de départ mais ca le pollue avec des informations inutiles pour ce niveau d'abstraction. C'est à ca que servent par exemple les profils UML qui sont des regroupements de stéréotypes.
On peut aussi les rajouter au modèle d'arrivée. Là la difficulté est de les placer dans le modèle alors que celui-ci n'existe pas. La troisième
est de l'associer à la transformation elle-même.
On se retrouve avec une jolie querelle de chapelle entre les protagoniste de UML et ses profils et les zélotes des DSL.
UML est standardisé et répandu. Il dispose d'outils graphiques et les profils sont faciles à mettre en oeuvre. Toutefois, il est trop riche pour les besoins et la mise au point des transformations ne s'en trouve pas facilitée. Les DSL quant à eux ne fournissent que le strict nécessaire. Mais on ne dispose pas encore de moyens simple pour en créer et notamment au niveau graphique même si ca s'améliore.
Autre reproche ca nécessite à chaque fois de s'approprier un nouveau formalisme.
[^] # Re: Ca a l'air vachement bien
Posté par Julien . Évalué à 10.
J'ai ma méta-classe "classe" qui hérite de la méta-classe "type", qui contient un méta-attribut "nom" et qui est lié à la méta-classe "attribut", elle même ayant un méta-attribut "type" etc ...
Ainsi, un programme écrit en java pourra se représenter comme une instance de ce méta-modèle. La classe "Personne" que j'ai écrit en java sera une instance de la méta-classe "classe", etc, etc ...
Bon, comme tu le dis, si on s'en arète là, ça s'apparente fortement à de l'onanisme cérébral.
Une idée c'est ensuite d'ajouter des méta-méthodes au méta-classes. Par exemple, une méta-méthode "rename" à la méta-classe "classe". Cette méthode renommera la classe mais aussi toutes les références à cette classe. Tu viens de créer un outil de refactoring de manière relativement aisée.
Une autre idée est l'approche MDA (Model Driven Architecture) de l'OMG (Object Management Group).
On commence par décrire l'application dans un modèle générique (disons UML puisqu'il vient aussi de l'OMG), c'est ce qu'on apelle le PIM (Platform Independant Model).
On utilise ensuite une transformation de modèle pour transformer notre application en son équivalent dans un modèle spécifique, par exemple Java, c'est ce qu'on appelle le PSM (Platform Specific Model).
Cette transformation est effectuée par un programme de niveau méta qui remplace chaque instance de "UML::Classe" par une instance de "Java::Classe" et ainsi de suite pour toutes les méta-classes du modèle de départ en s'appuyant sur un PDM (Platform Description Model).
On obtient ainsi un équivalent Java de notre application UML initiale.
Pourquoi s'emmerder à faire ça ? Eh bien, l'idée est de coder de manière indépendante de la plateforme d'exécution, puis, les spécificités de la plateforme sont décrites dans le PDM. Tu as donc une sorte de phase de compilation pour s'adapter à la plateforme et tu obtiens en résultat différent en fonction de tes ressources, de tes contraintes, etc ... Y compris, peut être dans un langage différent.
[^] # Re: Ca a l'air vachement bien
Posté par BAud (site web personnel) . Évalué à 5.
[^] # Re: Ca a l'air vachement bien
Posté par Thomas Douillard . Évalué à 4.
Cobol vers java, j'ai un pote qui a bossé là dessus.
L'idée, tu fais un meta-modèle de Cobol, un meta-modèle de java, et tu écris les règles de transformation au niveau du meta-modèle, genre au pif tu décris comment une description de fichier en cobol devient une une classe correspondante (un iterateur sur les lignes qui donne accès à chacune des collones, que sais-je, ...) avec qui va gérer ce fichier en java, etc, en ATL.
Pour info, une description de fichier en ça ressemble à ça:
http://www.labri.fr/perso/billaud/travaux/COBOL/poly-cobol-3(...)
un fichier est une suite d'enregistremnt, tu décris un enregistremnt un peu à la SQL en donnant les champs et leur taille.
Tu peux imaginer créer une classe en java qui a les attributs correspondants aux champs de l'enregistrement par exemple. Sauf que là tu fais ça au niveau du metamo
Ensuite tu as simplement les outils pour générer du java à partir de ton appli cobol : Tu écris une règle de transfo et tu transforme toutes les descriptions de fichiers en Cobol que tu veux en la classe correspondante en java.
[^] # Re: Ca a l'air vachement bien
Posté par fredFrisk . Évalué à 3.
[^] # Ouille ouille
Posté par Kerro . Évalué à 4.
Si Java a été créé, c'est bien pour cela.
Si les langages tels que Ruby, Python, etc ont été créés, c'est bien avec cela en tête (entre autre).
Si les bibliothèques pour le C ont été créées...
etc.
Je conçois qu'un programme tel qu'un défragmenteur de partitions NTFS avec un GUI Windows soit TRES lié à Windows: le programmeur n'en a probablement rien à fiche des autres systèmes.
Mais pour ceux qui s'en préoccupent, les bonnes options prises dès le départ font que le programme est portable avec des modifications très mineures.
En principe. :-) Car on a vite fait de dériver, d'aller dans une direction précise en oubliant un des buts initiaux.
[^] # Re: Ouille ouille
Posté par Thomas Douillard . Évalué à 4.
Genre : imagine, tu fais un modèle de blog, une démo d'un truc pour faire ça était passée ici il n'y a pas si logtemps.
Le modèle contient les infos genre (en très gros)
-> un blog c'est un ensemble de billets, un billet c'est un texte et un ensemble de commentaire (modèle de données)
-> pour poster un nouveau billet, on a besoin d'entrer un texte, dans un champ texte
-> pour afficher un billet, on affiche son texte, puis ses commentaire, puis un truc pour ajouter un commentaire
-> un ajout de commentaire ajoute un commentaire dans la liste des commentaire du billet
Vient ensuite la transformation, qui crée un programme blog à partir du modèle : les infos de la tranformation c'est par exemple :
-> pour récupérer le texte d'un commentaire on affiche un champ html "< input type=text>"
-> ...
C'est là qu'on voit la puissance : suivant la transformation tu peux : générer du code html, pour apache, générer du QT, ...
En gros tu laisse le programmeur se concentrer sur ce qu'il veut faire faire à son programme, c'est la transformation qui s'occupe de l'implémentation pure.
[^] # Re: Ouille ouille
Posté par left . Évalué à 4.
Si tant est que l'on puisse encore appeler ça un programmeur.
Q: Dis papa, c'est quoi un programmeur ?
A: C'est un monsieur qui a une énÖrme machine (eclipse (tm)(r) inside) et qui clique sur des boiboites pour créer un programme.
M'enfin je dis ça, il y a 20 ans on s'est fait la même réflexion quand on a sérieusement commencer à remplacer l'assembleur par du C. Dans 20 ans, on sera un ringard à programmer en utilisant encore le clavier ;)
[^] # Re: Ouille ouille
Posté par Thomas Douillard . Évalué à 5.
Genre tu monte en abstraction pour faire ressortir l'information essentielle.
[^] # Re: Ouille ouille
Posté par Kerro . Évalué à 3.
Le même genre que WinDev :-)
Comme l'indique 'left' ça fait polémique.
[^] # Re: Ouille ouille
Posté par Thomas Douillard . Évalué à 3.
D'ailleurs regarde du code ATL, tu verras qu'on est bien loin du Windev.
[^] # Re: Ouille ouille
Posté par nigaiden . Évalué à 6.
C'est une vision très optimiste et j'attends de voir un lecteur de MP3 multi-toolkit (Qt et GTK+) générés par une approche MDA.
Je vois quelques problèmes ; les transformations ont l'air d'être simples et magiques mais j'imagine qu'il y a de quoi s'arracher les cheveux pour écrire des règles de transformations qui marchent pour des cas un peu plus compliqués qu'un « Hello World ».
D'autre part il faut trouver une correspondance entre les méta-modèles ce qui n'est pas à la portée de tout le monde.
Enfin, ça a l'air de bien s'appliquer à la structure statique mais moins bien à l'aspect dynamique. Est-ce que vous proposez d'écrire le code en XML comme ce qu'on voit souvent pour les modèles ? Ou alors faut-il inclure du code directement dans les modèles (mais dans ce cas bye bye le PIM) ?
[^] # Re: Ouille ouille
Posté par Thomas Douillard . Évalué à 2.
Et peut-être (sûrement) que FredFrisk pourrait passer derrière moi pour corriger mes erreurs et mes approximations.
Mon exemple est tiré de la news http://linuxfr.org/2008/01/21/23592.html et la vidéo de démo est très parlante si tu veux mon avis.
Sur le papier, et sur la vidéo, à voir en pratique sur de vraies applications évidemment, on sent que le modèle de dev est vraiment souple et puissant. On peut spécifier les aspects statiques, mais aussi dynamiques style workflow et chaîne de traitements, etc, en se concentrant sur le coeur du truc et en évitant de noyer ce coeur dans un paquet de lignes de code, c'est vraiment ça la force du modèle.
Les faiblesses, sur la vidéo en tout cas : comme n'importe quelle approche générique, ça manque de "personnalisation" question présentation des données, mais
Alors, oui, n'importe qui ne peut pas forcément écrire les règles de transformations, mais en y réfléchissant :
-> si on reprends mon exemple de migration Cobol/java, si tu fais faire la migration par un développeur "à la mano", genre migrer pleins de formulaire,
* c'est répétitif, et il va forcément passer un peu de temps au début à réfléchir à comment migrer certains trucs, à se créer des patterns
* si tu fais faire ça par une équipe, tu vas donner des règles pour éviter de perpétuellement réinventer la roue, voire créer une biblio pour migrer
Ben c'est exactement le genre de travail que tu vas faire pour créer les règles de migration si tu veux mon avis.
Une fois que tu as fait ce travail le reste ce n'est qu'un boulot chiant et refaire sans cesse là même chose.
Bref, ce que permettent de faire ces technos : gagner en abstraction pour faire ressortir et se concentrer sur l'essentiel, automatiser, donc fournir des méthodologies toutes faites pour les migrations par exemple.
Tout ça c'est bien sûr modulo la complexité de la techno elle même et des biais technique qu'elle introduit, là je manque de recul pour ne voir ça que de loin.
Mais je suis plutôt optimiste:
-> C'est vraiment souple, tu peux représenter n'importe quoi comme un modèle, haut niveau, bas niveau, tout ce que tu veux
-> C'est vraiment générique, de la modélisation tu en fais dans tous les domaines, voire dans toutes les sciences, tu le fait DE TOUTE FAÇON d'une manière ou d'une autre quand tu codes, tes données, ton programme. Et du coup cette modélisation tu l'explicite et tu ne la noie pas dans le code.
-> C'est déjà utilisé avec succès industriellement.
C'est vraiment un niveau d'abstraction éle
[^] # Re: Ouille ouille
Posté par nigaiden . Évalué à 1.
Est-ce que Acceleo ne fait pas double emploi avec ATL ? Car finalement la génération de code consiste à passer d'un modèle (UML par exemple) à un autre (Java, SQL...).
Je vois bien l'intérêt et je fournis un autre exemple : à partir d'un modèle de données modélisé en UML on génère des scripts de création de table en SQL ainsi que des classes d'accès en C++. Je comprends le divertissement intellectuel qu'il y a à faire cela, mais je ne suis pas certain que l'on y gagne grand chose. Si les tables ont besoin d'index, est-ce qu'il faut « polluer » le modèle en faisant remonter cette information ? Quand le modèle change, comment sont générés les scripts « ALTER TABLE », est-ce qu'il faut méta-modéliser ce genre de changement ? Bref, j'ai l'impression que l'on retombe vite dans les détails d'implémentation donc les joies de l'abstraction ne durent pas très longtemps.
Vous l'avez compris, je ne suis pas très enthousiaste ; j'attends de voir les applications grand public développées en un éclair pour être persuadé des bienfaits du MDE. En même temps, si tout le monde était comme moi les choses n'évolueraient pas bien vite...
[^] # Re: Ouille ouille
Posté par fredFrisk . Évalué à 2.
Le fait d'utiliser de genre de technologie (Acceleo ou ATL) permet (très souvent) de gagner du temps en développement. De plus tu as travaillé à un niveau plus abstrait (grâce aux métamodèles), donc la maintenance est grandement facilitée. Si le modèle source change, il suffira de relancer la chaîne de transformations pour répercuter les changements. Par contre la réflexion modèle/métamodèle n'est pas forcement triviale au début.
[^] # Re: Ouille ouille
Posté par Bozo_le_clown . Évalué à 2.
Par exemple, à partir d'un Platform Independant Model on peut dériver des Platform Specific Model qui ciblent une architecture JEE , Dotnet , Zope ou encore LAMP. L'idée est là et un langage n'est rien sans ses bibliothèque de composants.
Java est donc "théoriquement "indépendant de l'OS mais passer du Java au C# n'implique pas uniquement un changement de langage mais aussi de "plateforme d'execution"
[^] # Re: Ca a l'air vachement bien
Posté par anonyme512 . Évalué à 7.
Ce que ça fait ces trucs-là, c'est faciliter la conception, et compliquer la maintenance (va chercher un bug d'implémentation perdu au milieu du squelette pondu par le merdier - déjà si il est pas lui-même merdé, le squelette).
Ca fait des années que ces trucs là c'est en gestation, et perso, j'arrive pas à m'y faire à toutes ces modes qui expliquent qu'il suffit d'écrire un méta-truc *ML pour quel tout marche automagiquement: c'est dit, je déteste l'IoC, la méta-pignolle UML, et autres. Tous ces "outils" sont faits par des gens qui n'ont jamais passé un mois à se faire ch... dans un service de support ou d'exploitation.
Dernièrement, j'ai vu une application pas hyper compliquée (workflows simples de gestion demandes utilisateurs), avec une volumétrie ridicule, arriver à ramer sur deux E450 avec 16Go de mémoire chacun et je sais plus combien de CPUs. Ah ouais le dev nickel, clica-clica XML UML conception machin.. ben bravo, tout ça pour remplacer une appli LAMP qui tournait sur un serveur monoprocesseur avec 1Go de mémoire.
Quand aux méta-modèles, j'ai assisté de près à la conception d'un super-méta-modèle multidimensionnel (un truc censé représenter tout le SI de la boite, en zoomant sur chaque composant "banalisé"), vendu très cher par une SSII peu scrupuleuse. Le résultat était à mourir de rire, et, au final, inimplémentable, ce qui révèle une difficulté supplémentaire de ces outils: ils sont difficiles à maitriser, parfois même par des gens relativement brillants.
C'est dit, je suis un vieux con ;-) Allez, ça finira bien par marcher un jour ! :-D
[^] # Re: Ca a l'air vachement bien
Posté par kbiger . Évalué à 2.
UML est dans un statut batare(non péjoratif ici), c'est à la fois un langage qui est au niveau métamétamodèle et au niveau métamodèle.
ATL permet de passer d'un modèle conforme à un MétaModèle d'un langage à un autre modèle conforme à un autre Métamodèle de langage en spécifiant la transformation.
Donc ATL prend en entrée un métamodèle spécifié dans un fichier ecore et un modèle conforme à ce métamodèle spécifié lui dans un fichier XMI.
Ce que l'on obtient donc est un fichier XMI qui est le modèle conforme au langage cible.
Ce même fichier xmi peut ensuite être tranformé par une extraction TCS vers un fichier texte si le langage est textuel par exemple.
Donc on peut créer une transformation Java->UML ou UML->Java mais se limiter à cette vision d'ATL est extrêmement réducteur, cette transformation est d'ailleurs disponible sur le Zoo d'ATL avec une transformation pour avoir la représentation d'UML dans un fichier DOT par exemple.
Enfin pour spécifier un métamodèle on le définit généralement en KM3, plus facile à manipuler qu'un fichier ecore qui est du xml.
De ce fichier KM3 on génère le fichier ecore correspondant.
Pour le modèle deux solutions, on peut peupler le xmi à la main ou alors on définit un fichier TCS qui va nous servir à l'injection pour obtenir un xmi conforme.
J'espère avoir été clair (j'ai un doute :) )
[^] # Re: Ca a l'air vachement bien
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: Ca a l'air vachement bien
Posté par fredFrisk . Évalué à 1.
De plus une fois que tu auras fait la transformation ATL entre le métamodèle Fortran 95 vers un autre métamodèle, il faudra utiliser un générateur de code pour l'opération inverse.
Si le reverse-engineering basé sur une approche "modèle" (MDA/MDE) t'intéresse, tu peux jeter un coup d'oeil sur le projet MoDisco (http://www.eclipse.org/gmt/modisco/).
[^] # Re: Ca a l'air vachement bien
Posté par kbiger . Évalué à 2.
ATL peut permettre la transformation direct d'un programme en fortran 95 vers un autre langage.
Il faut pour celà que quelqu'un ait fait le méta-modèle du langage fortran95, que l'autre langage (supposé textuel ici) ait également un méta-modèle disponible.
Il faut ensuite qu'il y ait une transformation ATL Fortran2OtherLanguage.
Et enfin il faut qu'il y ait un fichier TCS pour décrire la grammaire du langage.
Une fois ces étapes passées, tous tes programmes fortran95 opurront être transformés automatiquement, j'ai bien dit tous du moment que les précédentes étapes ont été bien programmées(par quelqu'un les ayant mis sur les zoos d'eclipse ou bien par toi).
[^] # Re: Ca a l'air vachement bien
Posté par fredFrisk . Évalué à 1.
Par contre je ne vois pas bien ce que viennent faire les zoos ici. Les zoos sont juste des bibliothèques de modèles, métamodèles, etc.
[^] # Re: Ca a l'air vachement bien
Posté par Farzad FARID (site web personnel) . Évalué à 3.
Je ne voudrais pas paraître trop négatif, mais je constate que beaucoup de réponses apportées dans cette discussion sur les applications concrètes de ces outils et concepts sont du type "Il n'y a qu'à...", "Il suffirait que quelqu'un écrive....", "Il faut que...", etc.
J'aimerais bien quelques réponses moins méta et plus réalistes ;)
Farzy (qui utilise sa main gauche pour taper ce message, main gauche qu'il manipule avec sa main droite, main droite qu'il tient et dirige avec les dents, pour que ça fasse méta-méta-niveau..).
[^] # Re: Ca a l'air vachement bien
Posté par fredFrisk . Évalué à 1.
[^] # Re: Ca a l'air vachement bien
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Dommage.
[^] # Re: Ca a l'air vachement bien
Posté par Bozo_le_clown . Évalué à 3.
2 approches seraient possibles à mon sens et de ce que je crois comprendre à lire nos 2 posteurs qui ont tenté de te répondre.
La première est de reverser à partir du fortran pour obtenir un modèle de plus haut niveau puis effectuer une transformation M2T à partir de ce modèle vers le langage cible.
Pour ce faire, ATL ne t'apporte rien, Acceleo pour la 2e étape.
L'inconvénient c'est qu'en remontant on perd de la sémantique du langage Fortran.
C'est pourquoi l'approche MDA préconise toujours une approche descendante à partir de modèles de plus haut-niveau.
L'autre approche est de considérer les 2 codes comme des modèles et les langages comme des métamodèles (on dispose d'un grammaire BNF). Ecrire une transformation de ce type ne doit pas être chose aisée à mon sens car chaque langage dispose de ces idiomes quand ils n'utilisent pas des paradigmes différents et ne parlons pas des bibliothèques standards. Après tu as tout le code à reprendre et étant donné le niveau de détail, j'ai peur que le refactoring soit gargantuesque
Si vraiment on doit migrer un SI d'une plateforme vers une autre, une chaîne viable serait peut-être la suivante mais elle n'a rien d'automatique non plus :
Remonter du fortran à un modèle de plus haut niveau représentant la plateforme (PSM) remonter à un modèle métier et affiner ce modèle avec la maitrise d'ouvrage. On dispose d'un capital précieux pour l'entreprise si par la suite on doit envisage de nouveaux projets de changement sur le SI.
Ensuite on peut dériver vers un PSM et avec une transfo M2T vers le code avec une approche descendante classique MDA
Voilà en espérant ne pas avoir été à coté du sujet.
J'imagine que ce n'est pas la réponse que tu espérais mais il faut garder à l'esprit que le MD apporte un gain de productivité pour certaines tâches répétitives et c'est là qu'est sa valeur ajoutée. Mais il est "encore" illusoire de vouloir développer un SI complet avec une approche MD.
C'est le doux rêve de l'OMG mais il est de plus en plus controversé par l'industrie et les faits.
[^] # Re: Ca a l'air vachement bien
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
En fait, je n'esperais pas grand chose si ce n'est de faire avancer le débat et essayer qu'un grand nombre de personne comprenne vraiment le sujet (dont moi). J'ai donc pris un exemple classique dans un laboratoire de recherche, pas si anodin que cela car il y a une grande histoire Fortran et pouvoir passer par exemple du Fortran à l'Ada serait dans certain cas intéressant.
Ta réponse finalement ne m'éclairicie malheureusement pas les idées. Tout cela me donne l'impression d'un truc énorme qui nécessite des projets énormes avec des moyens humains énormes...
[^] # Re: Ca a l'air vachement bien
Posté par Bozo_le_clown . Évalué à 2.
Le but est d'automatiser un certain nombre de tâches de programmation.
Plus elles sont génériques et plus elles sont réutilisables et plus on aura de retour sur l'investissement.
[^] # Re: Ca a l'air vachement bien
Posté par reno . Évalué à 2.
Les quelques tentatives de modélisation 'a postéiori' que j'ai vue ont explosée a cause de la complexité du code..
Personellement, ça me rend très, très méfiant ce genre de techno, je préférerais utiliser un langage de haut niveau comme Scala: c'est déjà pas mal comme abstraction, et ça reste un langage de programmation..
[^] # Re: Ca a l'air vachement bien
Posté par kbiger . Évalué à 1.
ATL n'est pas une nouvelle techno servant à générer automatiquement du code!
ATL passe d'un modèle à un autre modèle, ces deux modèles sont en XMI (comprenez XML grosso modo).
TCS permet de générer du code depuis un modèle en XMI. En l'occurence si cette génération est mauvaise ce ne sera ni à cause du langage TCS mais uniquement à cause du programmeur, lui seul définit la syntaxe du langage et donc lui seul est responsable de la génération.
Là je pense que c'est assez clair.
# Standard ?
Posté par Akbalder . Évalué à 1.
[^] # Re: Standard ?
Posté par Julien . Évalué à 2.
Sinon, pourquoi a t'on vu la disparition de CORBA des bureaux libres si c'était un standard ?
[^] # Re: Standard ?
Posté par Akbalder . Évalué à 1.
[^] # Re: Standard ?
Posté par fredFrisk . Évalué à 3.
# Outillage dans Eclipse
Posté par Cédric Brun (site web personnel) . Évalué à 1.
Editeurs, complétion , tout ce qu'il faut pour transformer des modèles de manière efficace et intuitives :)
[^] # Re: Outillage dans Eclipse
Posté par Bozo_le_clown . Évalué à 5.
C'est futé de faire de la pub pour ses petits collègues.
http://www.obeo.fr/pages/atl-pro/fr
http://www.obeo.fr/pages/acceleo-pro-compare/fr
Obeo est leader de ce projet hebergé pas la fondation Eclipse (leader : Cedric Brun).
Bon, on ne vous en veut pas pour une fois qu'une boîte française sort des produits innovants. Mais que je vous y reprenne pas :O)
[^] # Re: Outillage dans Eclipse
Posté par Cédric Brun (site web personnel) . Évalué à 1.
Si l'on compare les outils actuels de transformations de modèle (qu'on est évidemment ammené à utiliser quand on travaille chez Obeo) ATL est sans conteste le plus agréable à utiliser :)
Je dirais que c'est probablement également pour cela qu'Obeo à choisit de travailler à partir de cette base !
# C'est pour faire des BLURP ?
Posté par Houbaa . Évalué à 5.
[^] # Re: C'est pour faire des BLURP ?
Posté par Moonz . Évalué à 5.
# MDW
Posté par Pueblo2708 . Évalué à 1.
[^] # Re: MDW
Posté par fredFrisk . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.