Home » Modeling » UML2 Tools » Re: Still interested in mentorship
| Re: Still interested in mentorship [message #474251] |
Thu, 24 April 2008 11:09  |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Lars,
Perhaps you'd like to host this as a component in EMFT? I've added the
EMFT and UML2 Tools newsgroups to the "to" list of the reply, since I
imagine there would be quite a bit of interest in a generalized
refactoring framework, as well as specific support for Ecore and UML
refactoring.
Lars Schneider wrote:
> Hi,
>
> even though my proposal was "Not Selected" for GSoC I would like to be
> mentored apart from SoC. Here is my proposal again:
>
> > A Refactoring Plugin for EMF Models
> >
> > This work is planned as my diploma thesis and I am going to start on
> > May 1st, 2008
> >
> > Model driven software engineering emphases on models as the primary
> > artifacts in all phases of software development. Thus in this context,
> > high model quality is an essential prerequisite for high software
> > quality. Model refactoring is a kind of model optimization which
> > improves the structure of models while preserving the modeled
> > functionality.
> >
> > As a prequisite for my SoC-project, I developed a first refactoring
> > prototype for Eclipse UML2, an EMF-based implementation of the UML2.0
> > metamodel for the Eclipse platform. This prototype is available at:
> > http://www.mathematik.uni-marburg.de/~swt/modref
> >
> > It implements only a few refactorings, but can be extended by serving
> > an extension point for further refactorings. As model refactorings can
> > be considered as a special kind of model transformation, new
> > refactorings are developed by a transformation framework for EMF which
> > can be downloaded from: http://tfs.cs.tu-berlin.de/emftrans
> >
> > In my SoC-project, I intend to develop a refactoring plugin for EMF
> > which is not restricted to UML2 as underlying metamodel. This includes
> > the free choice of an EMF metamodel and a smooth integration of new
> > refactorings. The graphical user interface shall be improved and
> > realigned along the wizard based user interface for code refactorings
> > in Eclipse.
> >
> > Based on the existing prototype I want to implement at least the
> > following features.
> >
> >
> > Improvements to the user interface
> > Users being familiar with Eclipse surely know the code refactoring
> > facilities provided by Eclipse. Since model refactorings show
> > similarities to code refactorings, they should be handled in a similar
> > way. For code editing, the menu is extended by "Refactor" with all
> > available refactorings. Choosing a refactoring usually causes the
> > opening of a dialog. Here you can enter parameters for the selected
> > refactoring and either choose "OK" or "Preview". The preview is a
> > viewer showing the difference between the original source and the
> > refactored version. So, using wizards and previews is obvious and
> > changes should be highlighted.
> >
> > In addition to this improvement of the design I want to add further
> > functionalities. The following list is an extract from my personal
> > TODO list:
> >
> > * Changes in the properties view causes re-application of all
> > affected refactorings
> > * Saving the file with unapplied refactorings should not delete
> > them
> > * Some EMF models offer a visual editor (like UML2 Tools) which
> > could replace the default tree-based editor
> > (approx. 10 weeks)
> >
> >
> > Refactoring integration
> > Here, I want to address the problem of integrating new refactorings.
> > Refactorings are created using the EMF Model Transformer (EMT) which
> > automatically generates a new project containing the rule classes.
> > Thereafter the developer must accomplish several steps by hand which
> > are capable of being automated. The generated project does not serve
> > the extension point provided by my refactoring plugin. Since I do not
> > want to change the code of EMT the automation of this step could be
> > done by a script. Serving the extension point is done by a class
> > extending the abstract class "UMLRefactoringObject". In the actual
> > version (0.7) you have to create the whole class by yourself. My
> > intention is to use the class "Transformation" generated by EMT,
> > although there will still be the need for modifying this class by
> > hand. Finally the refactoring must be exported as a plugin. This is
> > done in Eclipse by choosing "File -> Export". This makes the creation
> > of refactorings easier such that the developer can concentrate on the
> > refactoring design itself only. (approx. 6 weeks)
> >
> >
> > Extension to EMF models
> > Another step is to extend the plugin to any kind of EMF model. In the
> > actual version (0.7), the plugin is limited to UML2 models which is
> > unnecessarily restricting because refactorings are created using the
> > EMF Model Transformer and UML2 is based on EMF. Model refactorings
> > created with the EMF Model Transformer are based on a metamodel. Thus
> > the plugin must decide which refactorings are applicable to the opened
> > model; e.g.UML2 refactorings are applicable to UML2 models, but not to
> > other EMF models. According to that the correct set of refactorings
> > must be loaded when opening a model. (approx. 6 weeks)
> >
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Still interested in mentorship [message #474253 is a reply to message #474251] |
Fri, 25 April 2008 08:05  |
|
Hi Lars,
I fear that I'm not the appropriate person to mentor you with respect to
your component proposal. But I feel the need to encourage you to continue
your work in this area because such a component is really missing from the
current portfolio!
Please don't give up ;-)
Cheers
/Eike
Ed Merks wrote:
> Lars,
> Perhaps you'd like to host this as a component in EMFT? I've added the
> EMFT and UML2 Tools newsgroups to the "to" list of the reply, since I
> imagine there would be quite a bit of interest in a generalized
> refactoring framework, as well as specific support for Ecore and UML
> refactoring.
> Lars Schneider wrote:
>> Hi,
>>
>> even though my proposal was "Not Selected" for GSoC I would like to be
>> mentored apart from SoC. Here is my proposal again:
>>
>> > A Refactoring Plugin for EMF Models
>> >
>> > This work is planned as my diploma thesis and I am going to start on
>> > May 1st, 2008
>> >
>> > Model driven software engineering emphases on models as the primary
>> > artifacts in all phases of software development. Thus in this context,
>> > high model quality is an essential prerequisite for high software
>> > quality. Model refactoring is a kind of model optimization which
>> > improves the structure of models while preserving the modeled
>> > functionality.
>> >
>> > As a prequisite for my SoC-project, I developed a first refactoring
>> > prototype for Eclipse UML2, an EMF-based implementation of the UML2.0
>> > metamodel for the Eclipse platform. This prototype is available at:
>> > http://www.mathematik.uni-marburg.de/~swt/modref
>> >
>> > It implements only a few refactorings, but can be extended by serving
>> > an extension point for further refactorings. As model refactorings can
>> > be considered as a special kind of model transformation, new
>> > refactorings are developed by a transformation framework for EMF which
>> > can be downloaded from: http://tfs.cs.tu-berlin.de/emftrans
>> >
>> > In my SoC-project, I intend to develop a refactoring plugin for EMF
>> > which is not restricted to UML2 as underlying metamodel. This includes
>> > the free choice of an EMF metamodel and a smooth integration of new
>> > refactorings. The graphical user interface shall be improved and
>> > realigned along the wizard based user interface for code refactorings
>> > in Eclipse.
>> >
>> > Based on the existing prototype I want to implement at least the
>> > following features.
>> >
>> >
>> > Improvements to the user interface
>> > Users being familiar with Eclipse surely know the code refactoring
>> > facilities provided by Eclipse. Since model refactorings show
>> > similarities to code refactorings, they should be handled in a similar
>> > way. For code editing, the menu is extended by "Refactor" with all
>> > available refactorings. Choosing a refactoring usually causes the
>> > opening of a dialog. Here you can enter parameters for the selected
>> > refactoring and either choose "OK" or "Preview". The preview is a
>> > viewer showing the difference between the original source and the
>> > refactored version. So, using wizards and previews is obvious and
>> > changes should be highlighted.
>> >
>> > In addition to this improvement of the design I want to add further
>> > functionalities. The following list is an extract from my personal
>> > TODO list:
>> >
>> > * Changes in the properties view causes re-application of all
>> > affected refactorings
>> > * Saving the file with unapplied refactorings should not delete
>> > them
>> > * Some EMF models offer a visual editor (like UML2 Tools) which
>> > could replace the default tree-based editor
>> > (approx. 10 weeks)
>> >
>> >
>> > Refactoring integration
>> > Here, I want to address the problem of integrating new refactorings.
>> > Refactorings are created using the EMF Model Transformer (EMT) which
>> > automatically generates a new project containing the rule classes.
>> > Thereafter the developer must accomplish several steps by hand which
>> > are capable of being automated. The generated project does not serve
>> > the extension point provided by my refactoring plugin. Since I do not
>> > want to change the code of EMT the automation of this step could be
>> > done by a script. Serving the extension point is done by a class
>> > extending the abstract class "UMLRefactoringObject". In the actual
>> > version (0.7) you have to create the whole class by yourself. My
>> > intention is to use the class "Transformation" generated by EMT,
>> > although there will still be the need for modifying this class by
>> > hand. Finally the refactoring must be exported as a plugin. This is
>> > done in Eclipse by choosing "File -> Export". This makes the creation
>> > of refactorings easier such that the developer can concentrate on the
>> > refactoring design itself only. (approx. 6 weeks)
>> >
>> >
>> > Extension to EMF models
>> > Another step is to extend the plugin to any kind of EMF model. In the
>> > actual version (0.7), the plugin is limited to UML2 models which is
>> > unnecessarily restricting because refactorings are created using the
>> > EMF Model Transformer and UML2 is based on EMF. Model refactorings
>> > created with the EMF Model Transformer are based on a metamodel. Thus
>> > the plugin must decide which refactorings are applicable to the opened
>> > model; e.g.UML2 refactorings are applicable to UML2 models, but not to
>> > other EMF models. According to that the correct set of refactorings
>> > must be loaded when opening a model. (approx. 6 weeks)
>> >
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Still interested in mentorship [message #474255 is a reply to message #474253] |
Fri, 25 April 2008 09:59 |
Lars Schneider
Messages: 50
Registered: July 2009 |
Member |
|
|
I won't give up because this is my diploma thesis. Even without
mentorship I will do my very best but it will become more difficult.
Eike Stepper wrote:
> Hi Lars,
>
> I fear that I'm not the appropriate person to mentor you with respect to
> your component proposal. But I feel the need to encourage you to
> continue your work in this area because such a component is really
> missing from the current portfolio!
>
> Please don't give up ;-)
>
> Cheers
> /Eike
>
>
>
>
> Ed Merks wrote:
>
>> Lars,
>
>> Perhaps you'd like to host this as a component in EMFT? I've added
>> the EMFT and UML2 Tools newsgroups to the "to" list of the reply,
>> since I imagine there would be quite a bit of interest in a
>> generalized refactoring framework, as well as specific support for
>> Ecore and UML refactoring.
>
>
>> Lars Schneider wrote:
>>> Hi,
>>>
>>> even though my proposal was "Not Selected" for GSoC I would like to
>>> be mentored apart from SoC. Here is my proposal again:
>>>
>>> > A Refactoring Plugin for EMF Models
>>> >
>>> > This work is planned as my diploma thesis and I am going to start on
>>> > May 1st, 2008
>>> >
>>> > Model driven software engineering emphases on models as the primary
>>> > artifacts in all phases of software development. Thus in this context,
>>> > high model quality is an essential prerequisite for high software
>>> > quality. Model refactoring is a kind of model optimization which
>>> > improves the structure of models while preserving the modeled
>>> > functionality.
>>> >
>>> > As a prequisite for my SoC-project, I developed a first refactoring
>>> > prototype for Eclipse UML2, an EMF-based implementation of the UML2.0
>>> > metamodel for the Eclipse platform. This prototype is available at:
>>> > http://www.mathematik.uni-marburg.de/~swt/modref
>>> >
>>> > It implements only a few refactorings, but can be extended by serving
>>> > an extension point for further refactorings. As model refactorings can
>>> > be considered as a special kind of model transformation, new
>>> > refactorings are developed by a transformation framework for EMF which
>>> > can be downloaded from: http://tfs.cs.tu-berlin.de/emftrans
>>> >
>>> > In my SoC-project, I intend to develop a refactoring plugin for EMF
>>> > which is not restricted to UML2 as underlying metamodel. This includes
>>> > the free choice of an EMF metamodel and a smooth integration of new
>>> > refactorings. The graphical user interface shall be improved and
>>> > realigned along the wizard based user interface for code refactorings
>>> > in Eclipse.
>>> >
>>> > Based on the existing prototype I want to implement at least the
>>> > following features.
>>> >
>>> >
>>> > Improvements to the user interface
>>> > Users being familiar with Eclipse surely know the code refactoring
>>> > facilities provided by Eclipse. Since model refactorings show
>>> > similarities to code refactorings, they should be handled in a similar
>>> > way. For code editing, the menu is extended by "Refactor" with all
>>> > available refactorings. Choosing a refactoring usually causes the
>>> > opening of a dialog. Here you can enter parameters for the selected
>>> > refactoring and either choose "OK" or "Preview". The preview is a
>>> > viewer showing the difference between the original source and the
>>> > refactored version. So, using wizards and previews is obvious and
>>> > changes should be highlighted.
>>> >
>>> > In addition to this improvement of the design I want to add further
>>> > functionalities. The following list is an extract from my personal
>>> > TODO list:
>>> >
>>> > * Changes in the properties view causes re-application of all
>>> > affected refactorings
>>> > * Saving the file with unapplied refactorings should not delete
>>> > them
>>> > * Some EMF models offer a visual editor (like UML2 Tools) which
>>> > could replace the default tree-based editor
>>> > (approx. 10 weeks)
>>> >
>>> >
>>> > Refactoring integration
>>> > Here, I want to address the problem of integrating new refactorings.
>>> > Refactorings are created using the EMF Model Transformer (EMT) which
>>> > automatically generates a new project containing the rule classes.
>>> > Thereafter the developer must accomplish several steps by hand which
>>> > are capable of being automated. The generated project does not serve
>>> > the extension point provided by my refactoring plugin. Since I do not
>>> > want to change the code of EMT the automation of this step could be
>>> > done by a script. Serving the extension point is done by a class
>>> > extending the abstract class "UMLRefactoringObject". In the actual
>>> > version (0.7) you have to create the whole class by yourself. My
>>> > intention is to use the class "Transformation" generated by EMT,
>>> > although there will still be the need for modifying this class by
>>> > hand. Finally the refactoring must be exported as a plugin. This is
>>> > done in Eclipse by choosing "File -> Export". This makes the creation
>>> > of refactorings easier such that the developer can concentrate on the
>>> > refactoring design itself only. (approx. 6 weeks)
>>> >
>>> >
>>> > Extension to EMF models
>>> > Another step is to extend the plugin to any kind of EMF model. In the
>>> > actual version (0.7), the plugin is limited to UML2 models which is
>>> > unnecessarily restricting because refactorings are created using the
>>> > EMF Model Transformer and UML2 is based on EMF. Model refactorings
>>> > created with the EMF Model Transformer are based on a metamodel. Thus
>>> > the plugin must decide which refactorings are applicable to the opened
>>> > model; e.g.UML2 refactorings are applicable to UML2 models, but not to
>>> > other EMF models. According to that the correct set of refactorings
>>> > must be loaded when opening a model. (approx. 6 weeks)
>>> >
>
>
|
|
|
| Re: Still interested in mentorship [message #474398 is a reply to message #474255] |
Fri, 25 April 2008 12:12 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Lars,
What about developing it as a component in EMFT? I'm sure there would
be significant interest in it and it's probably the most effective way
to demonstrate the relevance of your work in real world applications.
Please contact me at merks at ca dot ibm dot com if you are interested
in that...
Lars Schneider wrote:
> I won't give up because this is my diploma thesis. Even without
> mentorship I will do my very best but it will become more difficult.
>
> Eike Stepper wrote:
>> Hi Lars,
>>
>> I fear that I'm not the appropriate person to mentor you with respect
>> to your component proposal. But I feel the need to encourage you to
>> continue your work in this area because such a component is really
>> missing from the current portfolio!
>>
>> Please don't give up ;-)
>>
>> Cheers
>> /Eike
>>
>>
>>
>>
>> Ed Merks wrote:
>>
>>> Lars,
>>
>>> Perhaps you'd like to host this as a component in EMFT? I've added
>>> the EMFT and UML2 Tools newsgroups to the "to" list of the reply,
>>> since I imagine there would be quite a bit of interest in a
>>> generalized refactoring framework, as well as specific support for
>>> Ecore and UML refactoring.
>>
>>
>>> Lars Schneider wrote:
>>>> Hi,
>>>>
>>>> even though my proposal was "Not Selected" for GSoC I would like to
>>>> be mentored apart from SoC. Here is my proposal again:
>>>>
>>>> > A Refactoring Plugin for EMF Models
>>>> >
>>>> > This work is planned as my diploma thesis and I am going to start on
>>>> > May 1st, 2008
>>>> >
>>>> > Model driven software engineering emphases on models as the primary
>>>> > artifacts in all phases of software development. Thus in this
>>>> context,
>>>> > high model quality is an essential prerequisite for high software
>>>> > quality. Model refactoring is a kind of model optimization which
>>>> > improves the structure of models while preserving the modeled
>>>> > functionality.
>>>> >
>>>> > As a prequisite for my SoC-project, I developed a first refactoring
>>>> > prototype for Eclipse UML2, an EMF-based implementation of the
>>>> UML2.0
>>>> > metamodel for the Eclipse platform. This prototype is available at:
>>>> > http://www.mathematik.uni-marburg.de/~swt/modref
>>>> >
>>>> > It implements only a few refactorings, but can be extended by
>>>> serving
>>>> > an extension point for further refactorings. As model
>>>> refactorings can
>>>> > be considered as a special kind of model transformation, new
>>>> > refactorings are developed by a transformation framework for EMF
>>>> which
>>>> > can be downloaded from: http://tfs.cs.tu-berlin.de/emftrans
>>>> >
>>>> > In my SoC-project, I intend to develop a refactoring plugin for EMF
>>>> > which is not restricted to UML2 as underlying metamodel. This
>>>> includes
>>>> > the free choice of an EMF metamodel and a smooth integration of new
>>>> > refactorings. The graphical user interface shall be improved and
>>>> > realigned along the wizard based user interface for code
>>>> refactorings
>>>> > in Eclipse.
>>>> >
>>>> > Based on the existing prototype I want to implement at least the
>>>> > following features.
>>>> >
>>>> >
>>>> > Improvements to the user interface
>>>> > Users being familiar with Eclipse surely know the code refactoring
>>>> > facilities provided by Eclipse. Since model refactorings show
>>>> > similarities to code refactorings, they should be handled in a
>>>> similar
>>>> > way. For code editing, the menu is extended by "Refactor" with all
>>>> > available refactorings. Choosing a refactoring usually causes the
>>>> > opening of a dialog. Here you can enter parameters for the selected
>>>> > refactoring and either choose "OK" or "Preview". The preview is a
>>>> > viewer showing the difference between the original source and the
>>>> > refactored version. So, using wizards and previews is obvious and
>>>> > changes should be highlighted.
>>>> >
>>>> > In addition to this improvement of the design I want to add further
>>>> > functionalities. The following list is an extract from my personal
>>>> > TODO list:
>>>> >
>>>> > * Changes in the properties view causes re-application of all
>>>> > affected refactorings
>>>> > * Saving the file with unapplied refactorings should not
>>>> delete
>>>> > them
>>>> > * Some EMF models offer a visual editor (like UML2 Tools)
>>>> which
>>>> > could replace the default tree-based editor
>>>> > (approx. 10 weeks)
>>>> >
>>>> >
>>>> > Refactoring integration
>>>> > Here, I want to address the problem of integrating new refactorings.
>>>> > Refactorings are created using the EMF Model Transformer (EMT) which
>>>> > automatically generates a new project containing the rule classes.
>>>> > Thereafter the developer must accomplish several steps by hand which
>>>> > are capable of being automated. The generated project does not serve
>>>> > the extension point provided by my refactoring plugin. Since I do
>>>> not
>>>> > want to change the code of EMT the automation of this step could be
>>>> > done by a script. Serving the extension point is done by a class
>>>> > extending the abstract class "UMLRefactoringObject". In the actual
>>>> > version (0.7) you have to create the whole class by yourself. My
>>>> > intention is to use the class "Transformation" generated by EMT,
>>>> > although there will still be the need for modifying this class by
>>>> > hand. Finally the refactoring must be exported as a plugin. This is
>>>> > done in Eclipse by choosing "File -> Export". This makes the
>>>> creation
>>>> > of refactorings easier such that the developer can concentrate on
>>>> the
>>>> > refactoring design itself only. (approx. 6 weeks)
>>>> >
>>>> >
>>>> > Extension to EMF models
>>>> > Another step is to extend the plugin to any kind of EMF model. In
>>>> the
>>>> > actual version (0.7), the plugin is limited to UML2 models which is
>>>> > unnecessarily restricting because refactorings are created using the
>>>> > EMF Model Transformer and UML2 is based on EMF. Model refactorings
>>>> > created with the EMF Model Transformer are based on a metamodel.
>>>> Thus
>>>> > the plugin must decide which refactorings are applicable to the
>>>> opened
>>>> > model; e.g.UML2 refactorings are applicable to UML2 models, but
>>>> not to
>>>> > other EMF models. According to that the correct set of refactorings
>>>> > must be loaded when opening a model. (approx. 6 weeks)
>>>> >
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 22:55:51 GMT 2024
Powered by FUDForum. Page generated in 0.04163 seconds |
] 
Search
Help
Register
Login
Home
