Hi Pieter, this sounds all very interesting - yet it is more than I can digest in a short amount of time. Could you and Hans do me a favor? Please keep in touch with Thorsten Juergeleit so that he knows what's going on with your refactoring engine.
Thorsten, do you have some time to understand what SDM and graph rewriting really means and does? At the moment, this is too much for my head... :-) Cheers... Matthias > -----Original Message----- > From: Pieter Van gorp [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 25, 2003 11:32 AM > To: Matthias Bohlen > Cc: Torsten Juergeleit; [EMAIL PROTECTED] > Subject: Re: Refactoring support for AndroMDA > > > 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. > > > 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? > 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. > > 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
