[Andromda-devel] FW: model refactoring

[Matthias B. <mb...@mb...>]

Hi Attila,

wow, this sounds as if you are doing a lot of innovative work! Would you
please contact Torsten Juergeleit - he is experimenting with the
AndroMDA integration as an Eclipse plugin. I'll comment the rest of your
mail in detail, later...

Keep up the good work!
Matthias

---

Matthias Bohlen
"Consulting that helps project teams to succeed..."
http://www.mbohlen.de/


-----Original Message-----
From: Doroszlai Attila [mailto:da...@hs...]=20
Sent: Saturday, October 25, 2003 10:05 PM
To: Matthias Bohlen
Cc: Anthony Mowers
Subject: model refactoring


Matthias, Tony,

During the last six weeks or so I've been working on the model
refactoring issue, i.e. enabling AndroMDA to take model changes into
account and change the generated code instead of regenerating it.

I'd like to share with you what I've done so far to let you know how I'm
progressing, and to ask for your insights.

As I see it, there are three distinct parts to the task of model
refactoring:

1. Storing previous version(s) of the model.
2. During a code-generation run, figuring out what has changed
   since the previous version of the model.
3. Translate the changes of the model elements into changes in the
   source code.

In short, I'm done with the first one, mostly finished with the second
one and haven't yet touched the third one.


I used the Netbeans XMI writer to do the first task.  The model is saved
as an XMI file and is loaded during the next generation run. This works
even if the original model was not loaded by the MDRepositoryFacade.
The name of the XMI file can be specified for each run of the AndroMDA
Ant task by using a nested "history" element.  The whole incremental
stuff can also be switched off.


I'd say I've made good progress on the second part.  I used the JMI
reflective package to compare the two models and find the differences at
a low level in a metamodel-independent manner (let's call this process
exploration).  By low level differences I mean that I identify only
three kinds of changes: new elements, differring values and removed
elements.  I have only tried it yet with a static model, but it
correctly identified changes between two versions of the model.  The
changes are passed as objects from the comparator to the AndroMDA core,
which then passes them on to the cartridges.

AndroMDA processes one model element at a time, so it would be logical
to try to restrict the exploration of the differences to the model
element's context.  But how can I possibly tell which parts of the model
belong to the element in question and which don't?  Frankly, I think
this can only be answered by the cartridges.  What's more, this is
surely metamodel-dependent.

So now the exploration part goes over the whole model, or at least what
it can reach via associations starting from the model element AndroMDA
is processing.  This places the burden on the cartridges to decide which
changes to take into account when processing the model element.  I
haven't yet given much thought to it, but I think we need some kind of
metamodel-dependent descriptor that defines which elements and
associations the cartridge should take into account (and how, which
leads us to the topic of transformation definitions, but I won't go into
this now).


As for the third step, I've started to define an interface for
cartridges that support the incremental change of generated code. I've
also written a dummy cartridge which prints every change it's notified
of (and does so several times, since AndroMDA hands over the changes of
the whole model for every model element with the appropriate
stereotypes).

I don't know Eclipse JDT yet, but I know of another possibility
available even when not running AndroMDA as an Eclipse plug-in: InjectJ
(http://injectj.sf.net), which is a static source code transformation
engine.  It may be worth a look or two.  Anyway, I guess both of these
are only applicable to Java, but I'd definitely like to see this work on
SQL, too.


I have to test it more thoroughly, maybe cover some cases I have
forgotten so far, and clean up the code, then I'll be able to send you
the source for all this.  Until then, please share your thoughts on what
I described.


Attila