Home » Modeling » EMF » Final year undergraduate EMF based university project
| Final year undergraduate EMF based university project [message #387845] |
Thu, 23 September 2004 09:39  |
Eclipse User |
|
|
|
Hi everyone,
I'm planning a final year undergraduate computer science project which I
would attempt over the coming 9 months or so I've been hoping of looking
at something which would involved EMF.
One of the ideas I've been considering looking at is the issue of EMF
model migration, that is ensuring that when you change a metamodel that
you can create mappings to allow for old instances to be loaded in the
new generated editor. There is also the converse problem of allowing for
old editors to load the new instances.
My current ideas are very vague but my thoughts are that I would look to
extend the current ECore2Ecore editor so as to more clearly allow the
specification of mappings. I realise that there's very little
documentation for the editor and the associated mapping model but I hope
I can get to grips with it.
I would then add a code generation step to allow for the generation of
migration units, these would be pluggable pieces of code which can be
added to the model loading code of the generated editor and would
encapsulate the mapping between ECore files. They could also be used in
generated wizards for importing or exporting other models.
Possible extensions to this idea could be into areas such as supporting
other formats beyond ECore and also to look to using the Univerity of
Kents OCL implementation to specify constraints on the mappings between
the models.
I have also looked at the possibility of creating a more tradional
workflow modeler with 3 models, one for the UI, one for an intermediate
format and another for a runtime definition. I would add transformations
between them and allow for pluggable runtimes and UI definitions.
I am however very much open to suggestions for interesting pieces of
work which involve EMF or modeling in some manner. I am not familiar in
any great detail with what's currently going on in the EMF and wider
modeling community so feel free to suggest anything which you feel might
be appropriate.
Any ideas can be fairly research orientated and unknown or more well
understood. However a requirement of my dissertation is that it include
a large implementation section and to keep the academics happy it would
be helpful if there were a number of interesting intellectual challenges
associated with the work for me to talk about ;-)
My hope would be anything that I create over the 9 months I can feed
back to the community or maintain myself though I cannot accept
contributions as I work over the year as this is an individual project.
So any ideas that you guys have would be most welcome!
Many thanks,
Nick.
|
|
|
| Re: Final year undergraduate EMF based university project [message #387846 is a reply to message #387845] |
Thu, 23 September 2004 10:33  |
| Eclipse User |
|
|
|
Nick,
My comments are embedded inline below...
Nick Brett wrote:
> Hi everyone,
>
> I'm planning a final year undergraduate computer science project which
> I would attempt over the coming 9 months or so I've been hoping of
> looking at something which would involved EMF.
>
Great plan! Although I'm kind of biased. ;-)
> One of the ideas I've been considering looking at is the issue of EMF
> model migration, that is ensuring that when you change a metamodel
> that you can create mappings to allow for old instances to be loaded
> in the new generated editor. There is also the converse problem of
> allowing for old editors to load the new instances.
>
A capability new in EMF 2.0.0 is support for
XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. This capabilities allows
unrecognized data to be recorded "on the side" and even allows it to be
written out again, which is a reasonable way to solve the second half
of the above problem. If you want to read an old file and convert to a
new format on the fly, it's maybe not the best way.
> My current ideas are very vague but my thoughts are that I would look
> to extend the current ECore2Ecore editor so as to more clearly allow
> the specification of mappings. I realise that there's very little
> documentation for the editor and the associated mapping model but I
> hope I can get to grips with it.
>
Kenneth Hussey of the UML2 team has done some work similar to this.
It's a good approach for providing tool support for this kind of thing.
> I would then add a code generation step to allow for the generation of
> migration units, these would be pluggable pieces of code which can be
> added to the model loading code of the generated editor and would
> encapsulate the mapping between ECore files. They could also be used
> in generated wizards for importing or exporting other models.
>
There are many possible things one could generate from such a map. For
example, you could use it to do a cross model copy/conversion in Java or
to generate an XSLT script for transforming instances.
> Possible extensions to this idea could be into areas such as
> supporting other formats beyond ECore and also to look to using the
> Univerity of Kents OCL implementation to specify constraints on the
> mappings between the models.
>
> I have also looked at the possibility of creating a more tradional
> workflow modeler with 3 models, one for the UI, one for an
> intermediate format and another for a runtime definition. I would add
> transformations between them and allow for pluggable runtimes and UI
> definitions.
>
I'm not quite sure what this all implies.
> I am however very much open to suggestions for interesting pieces of
> work which involve EMF or modeling in some manner. I am not familiar
> in any great detail with what's currently going on in the EMF and
> wider modeling community so feel free to suggest anything which you
> feel might be appropriate.
>
We're just starting a planning phase for the new development cycle, so
our plans should become clear over the next month and will be made public.
> Any ideas can be fairly research orientated and unknown or more well
> understood. However a requirement of my dissertation is that it
> include a large implementation section and to keep the academics happy
> it would be helpful if there were a number of interesting intellectual
> challenges associated with the work for me to talk about ;-)
>
Mapping and model transformations seem like a pretty hot topic lately,
so it seems like a good area for you to focus.
> My hope would be anything that I create over the 9 months I can feed
> back to the community or maintain myself though I cannot accept
> contributions as I work over the year as this is an individual project.
>
Nick Boldt is just finishing up the setup for our EMF community/corner
which will provide folks like you with a vehicle by which you can share
your implementation with other interested folks, with the expectation
that donations that garner wide appeal will work their way into the base.
> So any ideas that you guys have would be most welcome!
>
> Many thanks,
> Nick.
>
>
>
|
|
|
| Re: Final year undergraduate EMF based university project [message #387849 is a reply to message #387846] |
Thu, 23 September 2004 16:59 |
| Eclipse User |
|
|
|
Thanks very much for your comments Ed.
I have a few queries to make sure I'm clear on what you're saying
embedded below:
Ed Merks wrote:
> Nick,
>
> My comments are embedded inline below...
>
> Nick Brett wrote:
>
>> Hi everyone,
>>
>> I'm planning a final year undergraduate computer science project which
>> I would attempt over the coming 9 months or so I've been hoping of
>> looking at something which would involved EMF.
>>
> Great plan! Although I'm kind of biased. ;-)
>
>> One of the ideas I've been considering looking at is the issue of EMF
>> model migration, that is ensuring that when you change a metamodel
>> that you can create mappings to allow for old instances to be loaded
>> in the new generated editor. There is also the converse problem of
>> allowing for old editors to load the new instances.
>>
> A capability new in EMF 2.0.0 is support for
> XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. This capabilities allows
> unrecognized data to be recorded "on the side" and even allows it to be
> written out again, which is a reasonable way to solve the second half
> of the above problem. If you want to read an old file and convert to a
> new format on the fly, it's maybe not the best way.
Just so I'm clear does this effectively mean that data which is
unrecognised is left alone in the model when loading and the user
doesn't see it in their loaded model but it is still stored back into
the XMI when they save in some manner?
I've looked at the Javadoc but don't fully understand the explanation
there. It mentions that unrecognised data is recorded in a map from
EObject to AnyTypes but I don't understand how you would use this or
what the default behaviour is with the property turned on. Is it the
responsibility of the user to add back the unrecognised data when saving
or is this done automagically in some manner?
>
>> My current ideas are very vague but my thoughts are that I would look
>> to extend the current ECore2Ecore editor so as to more clearly allow
>> the specification of mappings. I realise that there's very little
>> documentation for the editor and the associated mapping model but I
>> hope I can get to grips with it.
>>
> Kenneth Hussey of the UML2 team has done some work similar to this.
> It's a good approach for providing tool support for this kind of thing.
>
Great, I'll get in contact with him.
>> I would then add a code generation step to allow for the generation of
>> migration units, these would be pluggable pieces of code which can be
>> added to the model loading code of the generated editor and would
>> encapsulate the mapping between ECore files. They could also be used
>> in generated wizards for importing or exporting other models.
>>
> There are many possible things one could generate from such a map. For
> example, you could use it to do a cross model copy/conversion in Java or
> to generate an XSLT script for transforming instances.
That's interesting. I hadn't considered generating an XSLT script from
the mapping. I'll bear that in mind, I can see it could be a useful way
of representing the transformation in a standard form.
>
>> Possible extensions to this idea could be into areas such as
>> supporting other formats beyond ECore and also to look to using the
>> Univerity of Kents OCL implementation to specify constraints on the
>> mappings between the models.
>>
>> I have also looked at the possibility of creating a more tradional
>> workflow modeler with 3 models, one for the UI, one for an
>> intermediate format and another for a runtime definition. I would add
>> transformations between them and allow for pluggable runtimes and UI
>> definitions.
>>
> I'm not quite sure what this all implies.
Sorry I didn't explain this very well. My idea was only very vague, but
my thought was by splitting the application into three models I could
quite clearly define the ability to add new runtimes and also to add new
graphical notations to the front-end.
So there could be for example different runtimes which ran on different
platforms, e.g. A local java runtime, a web services run time. Or that
provided different quality of service guarantees.
And also have different views available on the workflow for different
levels of user skill or for different roles.
>
>> I am however very much open to suggestions for interesting pieces of
>> work which involve EMF or modeling in some manner. I am not familiar
>> in any great detail with what's currently going on in the EMF and
>> wider modeling community so feel free to suggest anything which you
>> feel might be appropriate.
>>
> We're just starting a planning phase for the new development cycle, so
> our plans should become clear over the next month and will be made public.
>
>> Any ideas can be fairly research orientated and unknown or more well
>> understood. However a requirement of my dissertation is that it
>> include a large implementation section and to keep the academics happy
>> it would be helpful if there were a number of interesting intellectual
>> challenges associated with the work for me to talk about ;-)
>>
> Mapping and model transformations seem like a pretty hot topic lately,
> so it seems like a good area for you to focus.
>
>> My hope would be anything that I create over the 9 months I can feed
>> back to the community or maintain myself though I cannot accept
>> contributions as I work over the year as this is an individual project.
>>
> Nick Boldt is just finishing up the setup for our EMF community/corner
> which will provide folks like you with a vehicle by which you can share
> your implementation with other interested folks, with the expectation
> that donations that garner wide appeal will work their way into the base.
>
>> So any ideas that you guys have would be most welcome!
>>
>> Many thanks,
>> Nick.
>>
>>
>>
|
|
|
| Re: Final year undergraduate EMF based university project [message #387853 is a reply to message #387849] |
Fri, 24 September 2004 07:34 |
| Eclipse User |
|
|
|
Nick,
More comments below...
Nick Brett wrote:
> Thanks very much for your comments Ed.
>
> I have a few queries to make sure I'm clear on what you're saying
> embedded below:
>
> Ed Merks wrote:
>
>> Nick,
>>
>> My comments are embedded inline below...
>>
>> Nick Brett wrote:
>>
>>> Hi everyone,
>>>
>>> I'm planning a final year undergraduate computer science project
>>> which I would attempt over the coming 9 months or so I've been
>>> hoping of looking at something which would involved EMF.
>>>
>> Great plan! Although I'm kind of biased. ;-)
>>
>>> One of the ideas I've been considering looking at is the issue of
>>> EMF model migration, that is ensuring that when you change a
>>> metamodel that you can create mappings to allow for old instances to
>>> be loaded in the new generated editor. There is also the converse
>>> problem of allowing for old editors to load the new instances.
>>>
>> A capability new in EMF 2.0.0 is support for
>> XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. This capabilities allows
>> unrecognized data to be recorded "on the side" and even allows it to
>> be written out again, which is a reasonable way to solve the second
>> half of the above problem. If you want to read an old file and
>> convert to a new format on the fly, it's maybe not the best way.
>
>
> Just so I'm clear does this effectively mean that data which is
> unrecognised is left alone in the model when loading and the user
> doesn't see it in their loaded model but it is still stored back into
> the XMI when they save in some manner?
>
Yes.
> I've looked at the Javadoc but don't fully understand the explanation
> there. It mentions that unrecognised data is recorded in a map from
> EObject to AnyTypes but I don't understand how you would use this or
> what the default behaviour is with the property turned on. Is it the
> responsibility of the user to add back the unrecognised data when
> saving or is this done automagically in some manner?
>
It's done automagically. During parsing, if some element/attribute is
encountered that can't be mapped to a feature of the object at the top
of the stack, an instance of org.eclipse.emf.ecore.xml.type.AnyType is
created and a mapping is added to getEObjectToExtensionMap from the top
stack object to that AnyType instance. Since the AnyType is the mapping
for XML Schema's anyType, it is able to represent arbitrary DOM, and so
we can record "arbitrary" information in that instance. After loading
is complete, the map can be inspected, and during save, when an EObject
is saved and has a mapping, the information for the corresponding
AnyType it maps to will be merged with the information actually on the
object. I could imagine a post-processing step where the side
information is mapped back into the model based on knowledge of meta
model changes.
>>
>>> My current ideas are very vague but my thoughts are that I would
>>> look to extend the current ECore2Ecore editor so as to more clearly
>>> allow the specification of mappings. I realise that there's very
>>> little documentation for the editor and the associated mapping model
>>> but I hope I can get to grips with it.
>>>
>> Kenneth Hussey of the UML2 team has done some work similar to this.
>> It's a good approach for providing tool support for this kind of thing.
>>
>
> Great, I'll get in contact with him.
>
>>> I would then add a code generation step to allow for the generation
>>> of migration units, these would be pluggable pieces of code which
>>> can be added to the model loading code of the generated editor and
>>> would encapsulate the mapping between ECore files. They could also
>>> be used in generated wizards for importing or exporting other models.
>>>
>> There are many possible things one could generate from such a map.
>> For example, you could use it to do a cross model copy/conversion in
>> Java or to generate an XSLT script for transforming instances.
>
>
> That's interesting. I hadn't considered generating an XSLT script from
> the mapping. I'll bear that in mind, I can see it could be a useful
> way of representing the transformation in a standard form.
>
>>
>>> Possible extensions to this idea could be into areas such as
>>> supporting other formats beyond ECore and also to look to using the
>>> Univerity of Kents OCL implementation to specify constraints on the
>>> mappings between the models.
>>>
>>> I have also looked at the possibility of creating a more tradional
>>> workflow modeler with 3 models, one for the UI, one for an
>>> intermediate format and another for a runtime definition. I would
>>> add transformations between them and allow for pluggable runtimes
>>> and UI definitions.
>>>
>> I'm not quite sure what this all implies.
>
>
> Sorry I didn't explain this very well. My idea was only very vague,
> but my thought was by splitting the application into three models I
> could quite clearly define the ability to add new runtimes and also to
> add new graphical notations to the front-end.
>
> So there could be for example different runtimes which ran on
> different platforms, e.g. A local java runtime, a web services run
> time. Or that provided different quality of service guarantees.
>
> And also have different views available on the workflow for different
> levels of user skill or for different roles.
>
>>
>>> I am however very much open to suggestions for interesting pieces of
>>> work which involve EMF or modeling in some manner. I am not familiar
>>> in any great detail with what's currently going on in the EMF and
>>> wider modeling community so feel free to suggest anything which you
>>> feel might be appropriate.
>>>
>> We're just starting a planning phase for the new development cycle,
>> so our plans should become clear over the next month and will be made
>> public.
>>
>>> Any ideas can be fairly research orientated and unknown or more well
>>> understood. However a requirement of my dissertation is that it
>>> include a large implementation section and to keep the academics
>>> happy it would be helpful if there were a number of interesting
>>> intellectual challenges associated with the work for me to talk
>>> about ;-)
>>>
>> Mapping and model transformations seem like a pretty hot topic
>> lately, so it seems like a good area for you to focus.
>>
>>> My hope would be anything that I create over the 9 months I can feed
>>> back to the community or maintain myself though I cannot accept
>>> contributions as I work over the year as this is an individual project.
>>>
>> Nick Boldt is just finishing up the setup for our EMF
>> community/corner which will provide folks like you with a vehicle by
>> which you can share your implementation with other interested folks,
>> with the expectation that donations that garner wide appeal will work
>> their way into the base.
>>
>>> So any ideas that you guys have would be most welcome!
>>>
>>> Many thanks,
>>> Nick.
>>>
>>>
>>>
|
|
|
Goto Forum:
Current Time: Sat Nov 08 05:59:34 EST 2025
Powered by FUDForum. Page generated in 0.03334 seconds |
Home