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
