[Andromda-devel] Re: Refactoring support for AndroMDA

[Pieter V. g. <pi...@pi...>]

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:pi...@pi...]
>> 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.
>>
>>
>
>
>