Hi Attila, > * Matthias Bohlen <[EMAIL PROTECTED]> [2003-07-29 21:46]: > > > For model-to-model transformations, I figure AndroMDA will... the quote below looks like it quotes one of my emails but in fact it quotes one of yours. ??
About model-to-model transformations: I don't think that model transformations are so good that we should do almost everything with it. The template mechanism has certain advantages. I think you will run into a maintenance problem if you try to do everything in Java, just like you will if you try to do everything in a template language (as Danilo already pointed out). I think, a correctly balanced mixture of model transformations and template usage will do the job. To support this opinion by examples and hard facts, I would have to think a lot more (or read a lot more of the OMG material) about model transformations. Then, I'll get back. Cheers... Matthias > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Doroszlai Attila > Sent: Saturday, August 02, 2003 11:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [Andromda-devel] AndroMDA 3.0 - vision for the > next generation > > > Hi Danilo, Matthias, Tony and others, > > * Matthias Bohlen <[EMAIL PROTECTED]> [2003-07-29 21:46]: > > > For model-to-model transformations, I figure AndroMDA will > > > need a mapping to each implementation language. If so, I'd > > > like to extend the Java cartridge with a generic > > > class/interface template and a transformer class with the > > > helper methods this requires. > > basically, this would be OK but I need a little more understanding > > which helper methods this would require. > > When you (Matthias and Danilo) mentioned model-to-model > transformations, I had the impression that you meant that > domain-specific stuff (like > EJB) could be done with them, and a generic Java cartridge > could handle the code generation. Starting out with a simple > model, the EJB cartridge would create the specific classes > and interfaces in the model, with all the ejbCreate and other > required stuff, and then let the Java cartridge do the final step. > > In order to generate Java code from the model, we need to > convert the properties of the model elements into Java > language elements. The current Helper classes do a large > part of this, like getting the name of a class etc. Some > modifiers, however, are not yet supported, at least I cannot > find them. For example, there is no reference to the > 'abstract', 'static', 'transient' and 'volatile' keywords. > Nested classifiers are also missing. > > So, there are three things that I think need to be done about > this (accompanied by a couple of notes and questions): > > 1. Support all language elements. > - Add a helper method for each missing group of modifiers that > would return the Java String representation of the model > element's > property. > - Add support for nested classifiers. > - What am I to do about 'strictfp'? Is it likely to be used? > > 2. Move these Java-specific parts of the code to the Java cartridge. > - I would also refactor them a little bit. I think splitting all > those helper methods into a number of classes wouldn't be a bad > idea. I have the following classes on my mind: > > - JavaElement: a general element of the Java language > - JavaClassifier: an interface or a class > - JavaClass: a class > - JavaInterface: an interface > - JavaAttribute: a field of a class > - JavaMethod: a method of a class > - JavaGenerator: the $transform object for the templates > > JavaGenerator would only have two functions: the > template would ask > the generator to hand over the java class or interface > element for > the class or interface model element. > > Each of the above element classes would handle its own source > generation from the model. So, for example, the JavaClass class > would have a getSpecifications() method , which would > return either > 'implements ThisInterface, ThatInterface' or ''. (It > may be called > getAbstractions(), but it might be confused with the > getAbstractness() method of the JavaClassifier class.) > > JavaClassifier would also provide a way to get its members and > nested classifiers. > > None of the Java* classes would let the templates know about the > meta-model. Also, they make the Proxy classes unnecessary, I > think. > > JavaGenerator might also have a cache to store > previously processed > elements. Currently, this wouldn't be much of a help, since for > each model element - template combination, a new > transform instance is > created in AndroMDAAntTask, but maybe we can find a way to avoid > this. > > 3. Write two templates: JavaClass and JavaInterface. > - With all the helper classes, this should be a snap. > - Maybe one template would be enough, after all. > > Moving the complexity from templates to Java sources may or > may not be a gain. This way, one could change the generated > source only by tinkering with Java sources. On the other > hand, some of the complexity is already in Java, that's the > point of Helper classes... > > So what do you think about these? Did you have something > like this on your minds when you talked about model-to-model > transformations? Can you think of situations where this > approach would be better? > > Attila > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites > including Data Reports, E-commerce, Portals, and Forums are > available now. Download today and enter to win an XBOX or > Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet _072303_01/01 _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
