Model refinement and model refactoring differ in that a model refinement is a model transformation from a higher to a lower level of abstraction whereas a model refactoring is a a model transformation at the same level of abstraction.are you sure that we mean the same thing? I was talking about
model transformations (from PIM to PSM and within the PSM),
something that has little to do with refactoring.
While I also consider these two things to be separate, model-to-model transformations would help a lot with the model refactoring part, too.
Model transformations are implemented as updates on metamodel classes. This can be done in a third generation programming language such as Java. The Eclipse refactorings are implemented as such, where the metamodel is the Java abstract syntax tree. Model driven transformations (MDA/QVT if you like) are implemented differently. In this context, a model transformation is a model as well. The advantages are that
- you can use a domain specific abstract syntax for model transformation (e.g. you can use a visual notation such as graph rewritings (SDM and equivalents))
- from the transformation models, you can generate implementations for different repositories.
To give an example of a model driven transformation of a refactoring, take a look at the SDM diagram for the pull up method refactoring from [1]. If you'd like to specify the refinement from "Business Entity" to "Entity Bean", you'd specify a transformation from the metamodel defining "Business Entity" (that would for example have an attribute "name" and a list of "responsabilities") to the metamodel defining "Entity Bean (that would for example have a "name", a list of "operations" with transaction attributes, etc. etc.). In practice, you would probably use more than one transformation (hence several metamodels, from very abstract, to fully detailed).
Does this explain why refactorings and refinements are so closely related? For simplicity, I will not come back on the differences w.r.t. intra-/inter-metamodel transformations for the time being.
I guess the source of all confusion comes from the fact that Attila is not only transforming models in his refactoring implementations, he also makes sure that the consistency with sources generated from these models is preserved. This "refactoring generated code" problem is indeed more complex than the conventional refactorings we know from IntelliJ and Eclipse. However, what conceptually happens under the covers is that
1. The abstract model is refactored
2. Where necessary, the code generator is rerun (e.g. for updating deployment descriptors)
3. The "refactoring reasoning engine" or "refinement repository" is queried to find out what concrete sources where generated fro this abstract model
4. A sequence of conventional refactorings are launched to refactor the sources (a "rename business entity" would for example lead to a "rename class" on the bean class, a "rename interface" on the remote and local interface, etc. Note that this is not only to update the definitions of these classes and interfaces (the interfaces are generated by xDoclet after all), but more importantly to update the manual code that makes use of them!)
5. [Attila can probably mention something I have overlooked here :) ]
To conclude, I'd like to summarize that within model driven refactoring, we have
1. model refinements (e.g. "business entity" to "fully deployable entity bean")
- a model driven implementation of such a refinement would be a transformation model from which JMI or EMF or ... code can be generated
2. model refactorings (e.g. "rename Java class", "rename business entity", "pull up Java method", ...)
- a model driven implementation of such a refactoring would be a transformation model from which JMI or EMF or ... code can be generated
3. refactorings for generated applications (e.g. "rename business entity", "pull up responsability", ...)
- by inspecting (1), and launching (2), these operations will maintain consistency across abstract and refined models and generated code
Do you still disagree or were we just using different terms for the same things (or vice versa).
Best regards, Pieter Van Gorp
[1] http://win-www.uia.ac.be/u/lore/refactoringProject/publications/Implementing_Refactorings_as_Graph_Rewrite_Rules_on_a_Platform_Independent_Metamodel.pdf
Doroszlai Attila wrote:
Hi,
are you sure that we mean the same thing? I was talking about
model transformations (from PIM to PSM and within the PSM),
something that has little to do with refactoring.
While I also consider these two things to be separate, model-to-model transformations would help a lot with the model refactoring part, too.
Cartridges will have to change the source code, possibly with the help of a source code transformation tool. This is easier if there is only one standard, generic Java cartridge, than if a number of cartridges have transformations into a subset of Java (maybe subset is not the correct word here, I mean EJB, Hibernate, Struts etc.).
The problem with the current cartridge design is that the transformation definitions are implicit and scattered across templates and helper classes. Thus, the source code changer of a cartridge would have to cover all elements generated by the cartridge and it would duplicate the logic of the cartridge. On the other hand, if the PSM was the same kind of model as the PIM is, and a separate cartridge generated the source code, then only the PSM-to-code transformation logic would have to be included in the source code changer module, decreasing the amount of duplicate logic. Furthermore, we might find a way to let the source code changer handle the initial code generation, too. In that case, no logic would have to be duplicated. I know that this would make the logic more difficult to express (no templates, at least not Velocity).
-Attila
ps: Matthias, I'm looking forward to your comments on my model refactoring e-mail (and code).
------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
