Hi Matthias,
> * A cartridge may now include model transformations, in addition to
> metafacades and templates. Model transformations are *.asm files from
> ATL. They operate on a source model, stored in a source extent and
> produce a target model, stored in a target extent. This means that a
> cartridge can now reference multiple extents in the repository. The
> cartridge descriptor needs an improvement so that you can specify
> which transformations from which extents and metamodels should be
> executed in which order.
As discussed earlier with Lofi, I propose to support multiple model
transformation languages in AndroMDA. Since ATL, MTL and SDM
transformations can be called from Java, we could simply use Maven
goals to setup chains of hybrid transformations. Using the cartridge
descriptor makes sense as well, but please make sure not to make it
dependent on *.asm files. It would also be nice if any transformation
language with a Java API could be used out of the box, even when we go
for the cartridge descriptor approach.
Best regards,
--
Pieter Van Gorp
Teaching and Research Assistant
FOrmal Techniques in Software engineering (FOTS)
University of Antwerp
Middelheimlaan 1
2020 Antwerpen - Belgium
Office: G.304
Phone: +32 3 265 38 71
Fax: +32 3 265 37 77
http://www.fots.ua.ac.be/~pvgorp/research/
http://motmot.sourceforge.net/
On 8/23/05, Matthias Bohlen <[EMAIL PROTECTED]> wrote:
> Hi to the AndroMDA developers,
>
> today, I thought about the necessary changes in AndroMDA's
> architecture when we want to include MOF/QVT/ATL-based model-to-model
> transformations in AndroMDA 4.0.
>
> I'll write a Confluence page about that, but I'll brainstorm here in
> concise form:
>
> * Our RepositoryFacade interface has to learn about extents. A
> repository can have multiple extents, just like directories inside a
> file system. In each extent, there can now reside a model or a
> metamodel. There must be a new method
> createExtent(name:String):ExtentFacade, and all the other methods
> readModel(), writeModel() and getModel() should be moved to the new
> interface "ExtentFacade".
>
> * A cartridge may now include model transformations, in addition to
> metafacades and templates. Model transformations are *.asm files from
> ATL. They operate on a source model, stored in a source extent and
> produce a target model, stored in a target extent. This means that a
> cartridge can now reference multiple extents in the repository. The
> cartridge descriptor needs an improvement so that you can specify
> which transformations from which extents and metamodels should be
> executed in which order.
>
> * A cartridge can now reference multiple metamodels. The cartridge
> descriptor needs an improvement so that you can specify which
> metamodels should be loaded when a certain cartridge is being
> initialized.
>
> * Templates now trigger on PSM metafacades, not on UML metafacades any
> more.
>
> * Metafacades now operate on arbitrary extents. So, metafacade.xml
> needs an improvement so that you can specify in which extent the
> metafacades will find their metaclasses that they are supposed to
> wrap.
>
> * Metafacades will not operate on the UML metamodel any more. They
> will operate on PSM metamodels supplied by cartridges or used
> independently from a cartridge (e.g. the 3GL metamodel). There will be
> less metafacades than before because many of their responsibilities
> will be moved to model transformations.
>
> * Cartridge.xml will now map PSM metafacades to templates.
>
> * Transformation libraries may now include global ATL transformations,
> too. These will be used for more than one cartridge at a time, that's
> why these "global" transformations are not kept inside a particular
> cartridge.
>
> * There will be new metamodels for PSM purposes. They will be able to
> use and extend each other, e.g. the Hibernate metamodel extends the
> 3GL metamodel. Metamodels will be generated from UML models, using the
> UML profile for MOF and the UML2MOF utility. The UML models will be
> MagicDraw modules that may reference each other.
>
> * Model elements inside PSM metamodels must have a "flavor". Flavors
> must be kept in a global dictionary. When the Spring cartridge runs a
> model transformation from UML to the Spring metamodel and then to the
> 3GL metamodel, it must tell the 3GL Class that it has the
> "SpringService" flavor (for example). The Spring cartridge must
> register its "services" outlet with the "SpringService" flavor. The
> Java cartridge will notice later on that has to generate code for a
> Class with the "SpringService" flavor and must redirect the output to
> the outlet which it finds in the global flavor dictionary.
>
> * Cartridge.xml will have to be modified so that a template does not
> care about the outlet any more. Outlets will now be chosen by the
> flavor of the generated artifact, instead.
>
> ---
>
> All this must be done to satisfy the following use cases:
>
> * Imagine the Spring cartridge: It starts a model transformation from
> the UML metamodel to the Spring metamodel and translates a UML
> <<Service>> class to an instance of the Service metaclass inside the
> Spring metamodel. Then, it starts a second model transformation from
> the Spring to the 3GL metamodel and translates the Spring Service to a
> 3GL interface, a 3GL *ServiceBase class and 3GL *ServiceImpl class. It
> also runs a template that translates the Spring Services to
> applicationContext.xml. Java code for the Services is not produced
> inside the Spring cartridge any more - this is done in the Java
> cartridge, now.
>
> * Imagine the Java cartridge: It generates Java code from an extent
> where a 3GL model is stored. It does not care about where the Class
> elements came from (i.e. which other cartridge did the model
> transformation). It runs templates on instances of the Class and
> Interface metaclasses of the 3GL metamodel.
>
> * Imagine a C# cartridge: It generates C# code from the same extent
> where the 3GL model is stored. It does not care about where the Class
> elements came from (i.e. which other cartridge did the model
> transformation). It runs templates on instances of the Class and
> Interface metaclasses of the 3GL metamodel and produces C# code from
> them.
>
> ---
>
> That's it for the moment. A Confluence page will follow. Quite a bit
> of stuff, isn't it?
>
> Cheers...
> Matthias
>
> ---
>
> Matthias Bohlen
> "Consulting that helps project teams to succeed..."
>
> Internet:
> http://www.mbohlen.de/
> [EMAIL PROTECTED]
>
> Phone: +49 (170) 772 8545
>
>
>
>
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
