Re: [Andromda-devel] FW: Model refactoring mathematics

[SainTiss <sai...@gm...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tony,

Apparently, I haven't explained the purpose of my thesis well enough... The=
=20
purpose is to create a tool which allows the input of UML diagrams which=20
specify a model transformation (i.e. to transform a model at level M1 in th=
e=20
MOF layered architecture), and then generates JMI code, which can then be=20
executed on an M1 model in MDR...
The only reason why refactoring can be linked to this, is that e.g. the "pu=
ll=20
up method" refactoring (which basically moves a method from a class to its=
=20
superclass) can be seen as such a model transformation. For example, suppos=
e=20
the model to be transformed is a UML diagram, and you'd like to pull up=20
method m() from class A to its superclass B. Then you could store this=20
diagram in MDR, execute the JMI code on it, and if you save the resulting=20
extent to XMI and load it in a CASE tool, the method would indeed have been=
=20
pulled up...
As said before, we should probably differentiate between this kind of "mode=
l=20
refactoring" and the "code-consistent refactoring" Attila is working on...=
=20

Anyway, since refactoring isn't the focus of my thesis, I'm afraid I can't=
=20
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 =3D r=
2*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 v=
ia
> 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 th=
at
> produced the transformation of M1 to M2 just by the comparison of M1 to M=
2?
> 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: and...@li...
> > [mailto:and...@li...]On 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 t=
he
> > 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:mb...@mb...]
> > > Sent: Wednesday, November 19, 2003 8:34 PM
> > > To: 'Doroszlai Attila'
> > > Cc: 'Anthony Mowers'; 'pi...@pi...'; '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, no=
w.
> > > I find this one of the most exciting things in the MDA field.
> > >
> > > See my comments below...
> > > Matthias
> > >
> > > > -----Original Message-----
> > > > From: Doroszlai Attila [mailto:da...@hs...]
> > > > 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) approac=
h.
> > > 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 t=
he
> > > 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 d=
id
> > > 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/sett=
er
> > > 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 bes=
t.
> > >
> > > > 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
> > > And...@li...
> > > 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=3D
> > =3D17SX
> > -----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
> > And...@li...
> > https://lists.sourceforge.net/lists/listinfo/andromda-devel

=2D --=20
Ark Linux - Linux for the Masses (http://arklinux.org)

Capitalism:=20
You don't have any cows. The bank will not lend you money to buy cows,=20
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 mil=
k.=20

In a world without walls and fences, who needs windows and gates?

Hans Schippers
2LIC INF
UA 2003-2004
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/wIvOXlnUYIbmLOQRAsARAJ9qqqdNeVAYWzgFyrLeUNrEKAiD1QCffW7g
Dv94DqGCEp63qSEkBw0KqR8=3D
=3D95DA
=2D----END PGP SIGNATURE-----