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:[EMAIL PROTECTED] 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 ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
