fredFrisk a écrit 7 commentaires

Sur le site ATL, il y a une section "Use Cases" présentant des exemples concrets d'utilisation de transformations de modèle : http://www.eclipse.org/m2m/atl/usecases/

Si mes souvenirs sont bons, les transformations dans MDWorkbench peuvent être écrites aussi en ATL ;-)

J'entendais reverse-engineering au sens large, c'est à dire passage du code vers un modèle. J'aurais sûrement dû employer le terme d'injection (qui est le passage d'un espace technique autre que le MDE vers l'espace technique MDE).

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.

ATL ne permettra pas directement de transformer Fortran 95 vers un autre langage. Cela va devoir nécessiter une étape de reverse-engineering code vers modèle.
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/).

Je dirais plutôt que les deux technologies Acceleo et ATL sont complémentaires. On peut très bien imaginer un enchaînement de plusieurs transformations ATL, puis une génération de code avec Acceleo. Par exemple, si tu veux fusionner deux modèles et ensuite générer du code à partir de ce modèle résultant, tu utiliseras une technologie de transformation de modèle à modèle (ATL) puis une technologie de transformation de modèle vers code (Acceleo).

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.

Pour voir à quoi ça ressemble, voici un lien vers un Hello World version ATL : http://www.eclipse.org/m2m/atl/doc/ATLUseCase_Families2Perso(...)

A la base, ATL était une implémentation de la spécif QVT. Mais à cause des longueurs de le process OMG pour cette spécif, ATL a continué à évoluer de son côté en privilégiant les besoins utilisateurs (concernant le langage) par rapport à un respect total de QVT. On décrit ATL comme un QVT-like.