Hi Matthias, thanks for your feedback.
Based on your earlier mails, I had already concluded that the (new) code generation component was not ideal for refactoring PIMs. Thanks to you, the draft paper I sent you really served its purpose (i.e. identifying uncomplete ideas, unclear sections, ...). The most important thing I learnt is that one PIM refactoring can be mapped to several traditional refactorings (e.g. renaming a domain entity leads to a rename for the bean *and* its home). In fact, I had overseen the need for a RRE. What I could achieve with the code preserver is that both classes were transformed (thanks to a regeneration of the home) but what I had overseen was that the manual code that used the home had to be transformed as well.
Anyway, the good thing is that I've got the big picture in front of me right now. I will update the paper today (final version submission is for next wednesday) and remove the AndroMDA related content that distracts the reader's attention from the primary contribution of the workshop paper, being ``generating source-consistent refactoring code from graph rewritings on a compact metamodel''. I will still present the code preserver because it is necessary if we want a compact metamodel *and* layout preservation.
I will present the lessons I learnt from my first shot on refactoring generative / MDA programs (e.g. written by AndroMDA) in another paper for the sake of clarity.
I understand that you may want to use Eclipse to minimize the effort/time to implement refactorings in AndroMDA. You could hardcode the JMI update code on AndroMDA's PIMs. However, together with my master student Hans Schippers, I will redo the Fujaba SDM code generation experiment with AndroMDA cartridges. Once finished, we will be able to generate the JMI PIM update code from graph rewrite rules, making the refactoring engine of AndroMDA model driven itself. Note that this doesn't eliminate the need for a RRE, that's still another project. A final (probably longer term) project could replace the hardcoded Eclipse refactoring libraries by generated refactoring libraries as we have described in the paper that I have sent to you. In that project, we would reuse Hans' metamodel transformator. In addition, a code preserver would be required. I think it's good that we've been able to chop this big problem into smaller chunks.The RRE could then translate the refactoring command that the user has made at the model level into several refactoring commands that instruct Eclipse how to do the refactorings at the lower level Java AST.
How do you think about this?
Thanks again for your feedback! I'll get back to you when Hans and I have got results with the AndroMDA model driven refactorings. Feel free to contact me if you have any questions or remarks in the meantime.
Best regards, Pieter Van Gorp.
On dinsdag, sep 23, 2003, at 18:30 Europe/Brussels, Matthias Bohlen wrote:
Hi Pieter,
finally, I have had the time to read your attached article. The proposal
that you make there seems feasible for models that have the same
abstraction level as the Java code. However, I can't see how this should
work using a true PIM in MDA.
Imagine the simple case in the AndroMDA Hibernate cartridge where a class in the UML model maps to at least two classes in the code: PersonService maps to PersonServiceBean and PersonServiceImpl. The operation PersonService.doSomething(x) in the UML model maps to two operations in the code: 1) PersonServiceBean.doSomething(x) which establishes the Hibernate session context and then delegates to... 2) another operation called PersonServiceImpl.handleDoSomething(x, HibernateSession) that really implements the business logic.
The catch clauses of the two operations differ, the names differ, the
number of parameters differ, etc. You will see that the code preserver
you describe would have to deal with the two operations at the
implementation level and map them back to one operation at the PIM level
which seems virtually impossible to me.
A more promising approach (in my opinion) would be to let AndroMDA support the refactoring process. An AndroMDA cartridge could create a representation of the model transformation which it does during code generation. For example it could pass a graph to the refactoring reasoning engine (RRE) which extends the PIM metaclasses with information about the mapping to the PSM. The RRE could then translate the refactoring command that the user has made at the model level into several refactoring commands that instruct Eclipse how to do the refactorings at the lower level Java AST.
How do you think about this?
Cheers... Matthias
-----Original Message----- From: Pieter Van gorp [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 6:15 PM To: Matthias Bohlen Subject: Re: Refactoring support for AndroMDA
Hi Matthias,
this is VERY interesting! I am very curious to read you paper.Thank you for your interest, this always makes work more fun :)
Also thanks for the info on the overwriting mechanism. I think we don't need to modify AndroMDA itself to implement the ideas from our paper. I've attached the PDF of our submission to www.fujaba.de/fdays/. If you have any feedback, we can still integrate it in our camera ready version for 17 september.
Best regards, Pieter Van Gorp.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
