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
