Sorry Hans, I confused your work with Attilla's. I really meant to send Attilla the question that I sent you.
Tony > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of SainTiss > Sent: Sunday, November 23, 2003 2:28 AM > To: Tony Mowers > Cc: AndroMDA-devel Mailing > Subject: Re: [Andromda-devel] FW: Model refactoring mathematics > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Tony, > > Apparently, I haven't explained the purpose of my thesis well > enough... The > purpose is to create a tool which allows the input of UML diagrams which > specify a model transformation (i.e. to transform a model at > level M1 in the > MOF layered architecture), and then generates JMI code, which can then be > executed on an M1 model in MDR... > The only reason why refactoring can be linked to this, is that > e.g. the "pull > up method" refactoring (which basically moves a method from a > class to its > superclass) can be seen as such a model transformation. For > example, suppose > the model to be transformed is a UML diagram, and you'd like to pull up > method m() from class A to its superclass B. Then you could store this > diagram in MDR, execute the JMI code on it, and if you save the resulting > extent to XMI and load it in a CASE tool, the method would indeed > have been > pulled up... > As said before, we should probably differentiate between this > kind of "model > refactoring" and the "code-consistent refactoring" Attila is > working on... > > Anyway, since refactoring isn't the focus of my thesis, I'm > afraid I can't > answer your algebra-related questions... > > Cheers, > > Hans > > On Saturday 22 November 2003 19:26, Tony Mowers wrote: > > Hans, > > > > There is a basic set of questions that come to my mind after having read > > Matthias' and your comments. > > > > I would imagine an important component of your thesis might > have something > > to say, or at least refer to other papers, about the 'Algebra of Model > > Refactorings'. Some of the questions that entered my mind while reading > > the e-mail were: > > > > 1) What set of model refactoring types will you be considering in your > > problem? Let us call that set of refactorings R. > > > > 2) Can anything significant be said about the algebra of the > refactorings > > in R. For example are the elements of R reflexive (i.e. does > r1*r2 = r2*r1 > > for all r1,r2 elements of R)? I would think not. > > > > Just out of curiosity does R define a group? > > > > 3) Assume a model M1 and a model M2 where M1 has been > transformed to M2 via > > only some subset of refactorings from R. Let us call that subset of > > transformations R1. Is it always possible to deduce the > elements of R1 that > > produced the transformation of M1 to M2 just by the comparison > of M1 to M2? > > Can anything about the existence and uniqueness of R1 be said? > > > > I believe that is an important question given the approach you are > > pursuing. > > > > 4) Now assume a model M1 and a model M2 where M1 has been transformed by > > not only some subset of refactorings from R but also by some > refactorings > > not in R. Let us again call the subset of refactorings that > are of R that > > are part of the transformation R1. How are your findings from question 3 > > impacted by the extra the non R based elements in the transformation. > > > > It seems to me that your masters thesis is actually pursuing two > > potentially hard problems. > > 1) the reverse engineering of refactorings from model comparisons > > 2) the propragation of refactorings through MDA cartridges > > > > The questions I asked in the above text are only from problem 1. > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf > Of SainTiss > > > Sent: Friday, November 21, 2003 11:22 AM > > > To: AndroMDA-devel Mailing > > > Subject: Re: [Andromda-devel] FW: Model refactoring mathematics > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Hi, > > > > > > What I'm doing for my thesis, doesn't really have an obvious > > > place in this > > > particular concept... What the model transformer could be > used for in the > > > context of refactorings, is visually specifying certain common > > > refactorings, > > > from which deployable JMI code would be generated, which could > > > then be used > > > as a building block for a user who doesn't want to change his model > > > manually... However, in the situation described below, chances > > > are that the > > > model *has* been changed manually, and then the code needs to be > > > synchronized... From this point, the model transformer isn't > > > useful anymore, > > > and other mechanisms are needed... > > > > > > As stated in previous mails, the most important application of model > > > transformation is probably PIM-to-PSM, but that's not really > > > relevant to the > > > refactorings Attila's working on I think... > > > > > > Aspects beyond model transformations are more relevant to > > > Pieter's research > > > than mine atm... > > > > > > Cheers, > > > > > > Hans > > > > > > On Wednesday 19 November 2003 21:18, Matthias Bohlen wrote: > > > > -----Original Message----- > > > > From: Matthias Bohlen [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, November 19, 2003 8:34 PM > > > > To: 'Doroszlai Attila' > > > > Cc: 'Anthony Mowers'; '[EMAIL PROTECTED]'; 'SainTiss' > > > > Subject: Model refactoring mathematics > > > > > > > > > > > > Hi Attila, > > > > > > > > sorry that it took me sooooo long to respond - it'll happen now. I'm > > > > impressed that so many people think about model-based > refactoring, now. > > > > I find this one of the most exciting things in the MDA field. > > > > > > > > See my comments below... > > > > Matthias > > > > > > > > > -----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. > > > > > > > > We could call this the "compare, generate, propagate" > (C-G-P) approach. > > > > I thought of an alternative approach: "generate, compare, propagate" > > > > (G-C-P). First, generate code as we do it today, then compare on the > > > > code level and propagate changes into the hand-written > code. However, > > > > as one model element maps to several elements in code, this solution > > > > will possibly cause more comparison overhead. > > > > > > > > So, let's toss that idea and stick to your C-G-P approach. > > > > > > > > > In short, I'm done with the first one, mostly finished with > > > > > the second one and haven't yet touched the third one. > > > > > > > > This sounds like you have worked very fast! > > > > > > > > > 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. > > > > > > > > Sounds good. An optimization might be to use a simple > <copy> tag in the > > > > ant file to save the old XMI. However, when you run inside > a CASE tool > > > > like Poseidon and operate on an in-memory model, the XMI writer > > > > approach is better. > > > > > > > > > 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. > > > > > > > > OK, so you have solved the "C" phase in C-G-P. I think, the > way you did > > > > it is good because it is generic: a comparator that does not know > > > > anything and simply computes the set of all changed model elements. > > > > Each cartridge should know how to deal with the results of the "C" > > > > phase. > > > > > > > > Let's name the set of changed model elements - call it "SoCM", for > > > > example. I'll use that name below. > > > > > > > > So, till here, we have "C" done by you, "G" done by AndroMDA, so all > > > > that is left is "P". As far as I have understood Pieter and Hans at > > > > Antwerp University, they have started to solve "P", right? If Pieter > > > > can really describe what "P" means in 20 lines of email > text, maybe we > > > > can skip this problem and use the Antwerp solution. But, > let's pretend > > > > for a moment that we don't have that solution. > > > > > > > > > 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. > > > > > > > > Yes, sure. > > > > > > > > > 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. > > > > > > > > It seems like a cartridge is required to compute a kind of (possibly > > > > transitive) closure TC(m) of a model element m - this is the set of > > > > input model elements that will be read by the cartridge when it > > > > generates code for m. Example: if m is an <<Entity>> class, TC(m) > > > > contains at least: > > > > * all the attributes and methods in m > > > > * all association links connected to m > > > > * all association links on "the opposite end" of each association > > > > * all classes that can be reached via associations > > > > * all other classes that can be reached via an <<EntityRef>> or > > > > <<ServiceRef>> dependency > > > > * an exception class that can be reached via an <<Exception>> > > > > dependency * the superclass of m > > > > * etc. etc. > > > > > > > > Each cartridge should be able to formally describe how TC(m) is > > > > computed. Phew - quite a complex task in itself! Well, let's assume > > > > that can be done somehow and proceed. > > > > > > > > Once the cartridge has got TC(m), the cartridge can intersect TC(m) > > > > with SoCM (see above). For each model element mc ("c" for "changed") > > > > that is a member of SoCM and TC(m), the cartridge has to > compute a set > > > > of "propagate commands" PC(mc) that tell the Java refactoring engine > > > > how to do a change at the code level. > > > > > > > > Example: > > > > * Take two entity classes: a class Person and a class Address. > > > > * Person has an association to Address with the role name > > > > "homeLocation" at the association end near Address. > > > > * The user changes this role name to "homeAddress". > > > > > > > > What should happen? > > > > > > > > * SoCM contains one element (mc) of type AssociationEnd with the new > > > > name "homeAddress". > > > > * TC(Entity) also contains mc so that mc is a member of the > > > > intersection of both sets. > > > > * The cartridge knows that association end names generate > getter/setter > > > > names. > > > > * So, the cartridge calculates PC(mc) and decides to produce a > > > > propagate command "change getter/setter name to getHomeAddress and > > > > setHomeAddress" and sends it to the Java refactoring engine. > > > > * The Java refactoring engine (Eclipse in that case) > changes the name > > > > "getHomeLocation" to "getHomeAddress" wherever it finds it (same for > > > > the setter). > > > > > > > > > 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). > > > > > > > > Hmmmm ... specifying how a cartridge should compute TC(m) is > > > > non-trivial. Maybe, the guys around Pieter have an idea. > > > > > > > > > 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). > > > > > > > > Maybe, the core should keep a reference to SoCM so that > each cartridge > > > > can reference it on demand. SoCM should not be passed to > the cartridge > > > > each time a model element is processed. > > > > > > > > > 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. > > > > > > > > InjectJ looks good. It looks much more generic than Eclipse > JDT. We'll > > > > have to look at all the propagate commands that the cartridges will > > > > spill out, then we can decide which refactoring engine > would work best. > > > > > > > > > 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. > > > > > > > > OK. Thanks. So much for my thoughts. Now, Pieter, Hans and > the others > > > > should add their comments and ideas. > > > > > > > > > Attila > > > > > > > > Cheers... > > > > Matthias > > > > > > > > P.S.: Oh boy, this was far more than 20 lines! Sorry! :-) > > > > > > > > --- > > > > > > > > Matthias Bohlen > > > > "Consulting that helps project teams to succeed..." > > > > http://www.mbohlen.de/ > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: SF.net Giveback Program. > > > > Does SourceForge.net help you be more productive? Does it > > > > help you create better code? SHARE THE LOVE, and help us help > > > > YOU! Click Here: http://sourceforge.net/donate/ > > > > _______________________________________________ > > > > Andromda-devel mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/andromda-devel > > > > > > - -- > > > Ark Linux - Linux for the Masses (http://arklinux.org) > > > > > > Capitalism: > > > You don't have any cows. The bank will not lend you money to buy cows, > > > because you don't have any cows to put up as collateral. > > > > > > Representative Democracy: > > > You have two cows. Your neighbors pick someone to tell you who > > > gets the milk. > > > > > > In a world without walls and fences, who needs windows and gates? > > > > > > Hans Schippers > > > 2LIC INF > > > UA 2003-2004 > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.2.3 (GNU/Linux) > > > > > > iD8DBQE/vmXwXlnUYIbmLOQRAuKMAJ0SL5s7KmzmxwiSUwgBy6ka3sqfhgCfUGP7 > > > wFMAHDLBO6AAZi1u11DrWvU= > > > =17SX > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: SF.net Giveback Program. > > > Does SourceForge.net help you be more productive? Does it > > > help you create better code? SHARE THE LOVE, and help us help > > > YOU! Click Here: http://sourceforge.net/donate/ > > > _______________________________________________ > > > Andromda-devel mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/andromda-devel > > - -- > Ark Linux - Linux for the Masses (http://arklinux.org) > > Capitalism: > You don't have any cows. The bank will not lend you money to buy cows, > because you don't have any cows to put up as collateral. > > Representative Democracy: > You have two cows. Your neighbors pick someone to tell you who > gets the milk. > > In a world without walls and fences, who needs windows and gates? > > Hans Schippers > 2LIC INF > UA 2003-2004 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/wIvOXlnUYIbmLOQRAsARAJ9qqqdNeVAYWzgFyrLeUNrEKAiD1QCffW7g > Dv94DqGCEp63qSEkBw0KqR8= > =95DA > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Andromda-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/andromda-devel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
