Hi Matthias, sorry for the late answer I was in holidays...
we are on the brink of starting the design for AndroMDA 4.0, including quite exciting new features like model to model transformations, using a QVT approach. See the latest postings on the andromda-devel mailing list to get an idea. My question to you today: Would you be willing to join in and help us with design and development of the new release for the next 12 months or so? Maybe, one of your students would like to write his diploma thesis on one of the subjects and implement the code for it?
it's a pitty that I haven't finished my article about AndroMDA and MTL yet... But I'm quite sure that I'll finish it very soon (because all the example codes are already finished...). I like the idea of the ability to "plug" (transformation chainning) model-model transformation languages into AndroMDA (MTL, ATL, ModTransf, ...). With this style we will be able to use the right tool for the right job. Since each model-model transformation language has its own advantages and disadvantages just like common programming languages (imperative, declarative, function-oriented, graph-oriented, ...). Here are for example the advantages of MTL: The real advantage of MTL *is* the imperative style, since all these transformation languages are comparable with "programming languages". As you can see the imperative style programming languages are mostly easier to understand for many "normal" developers (Java, VB vs. Prolog for example). I see MTL to have a real potential for common model-model transformation languages, because: - it is imperative, thus easy to understand and - it has a similar approach to Java concepts, thus easy to learn for beginners who already understand Java (classes, packages, etc.). Also, you already have a lot of "good practices" and "good patterns" in imperative languages like refactoring, code management, etc., so that you can apply all of these knowledge to MTL as well. The ultimate target is that we can reach "a model-driven transformation language" (model-model and model-text) with AndroMDA (this is what MotMot tries to reach if I'm not wrong... Peter, could you explain this?). So, we can use UML to define our transformation and just use the "correct" cartridges (ATL, MTL, ModTransf, etc.) to generate all or some of the transformation codes needed. I will surely support AndroMDA as good as possible. In my part I will concentrate on the "user perspective" of those model transformation languages, since the best concept won't work if you cannot get acceptance from the users (writing simple articles, examples, finding some use cases, etc.) :-) Best regards, -- --------------------------------------------------- Blasius Lofi Dewanto --------------------------------------------------- OpenUSS - Open University Support System http://openuss.sourceforge.net --------------------------------------------------- E-Mail : [EMAIL PROTECTED] --------------------------------------------------- ------------------------------------------------------- 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 _______________________________________________ Andromda-devel mailing list Andromda-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/andromda-devel
