Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » help with existing meta data repository mapping
help with existing meta data repository mapping [message #383876] Mon, 12 January 2009 05:26 Go to next message
Eclipse User
Originally posted by: brian.silberbauer.gmail.com

Hi all

I'm new to the eclipse modelling world and there is a lot of new concepts
and libraries and plugins, so I hope I'm posting at the right place:

I have a client who has an existing application extracting meta
information from various sources and storing it in a propriety format in
a RDB and can view it through a custom built viewer.

We would like to be able to use the visualization tools and query tools
available on the existing meta data repository, what would you recommend
the best way to create this mapping?

Possibilities we've seen so far would be to map to EMF by either
exporting portions to XMI and importing that, generating the EMF code
directly from the repository or creating a custom CDO implementation.

Any help, comments would be appreciated, I'm in acronym overload.

Brian
Re: help with existing meta data repository mapping [message #383878 is a reply to message #383876] Mon, 12 January 2009 20:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Brian,

Comments below.

Brian Silberbauer wrote:
> Hi all
>
> I'm new to the eclipse modelling world and there is a lot of new concepts
> and libraries and plugins, so I hope I'm posting at the right place:
>
Modeling is usually not the right place, because it's just a general
catch-all for the top-level modeling project...
> I have a client who has an existing application extracting meta
> information from various sources and storing it in a propriety format in
> a RDB and can view it through a custom built viewer.
>
> We would like to be able to use the visualization tools and query tools
> available on the existing meta data repository, what would you recommend
> the best way to create this mapping?
>
This is certainly a very general question, so it does seem reasonable to
ask it here...

Most of the Eclipse modeling stack of technology is built around Ecore
as the core meta model. So much of your question about mapping is how
to map whatever meta model/information you have to Ecore...
> Possibilities we've seen so far would be to map to EMF by either
> exporting portions to XMI and importing that, generating the EMF code
> directly from the repository or creating a custom CDO implementation.
>
It's "something" -> XMI -> "instance of an Ecore model" sounds like a
level on indirection you shouldn't need. We can only read XMI because
there is an Ecore model onto which the elements and attributes map. So
if you can map "something" to XMI then you can map "something" directly
onto an instance (an EObject). Things like Teneo and CDO (and JCRM for
that matter) can help help bridge the gap between a repository and
EObject instances.
> Any help, comments would be appreciated, I'm in acronym overload.
>
Yes, that sucks. But to give concrete advice, I think we need more
information than that you have a "format in RDB". After all that's
just an acronym to add to the soup. My knee jerk response would be to
say that Hibernate helps map RDB to Java objects and Teneo provides
integration with Hibernate and hence is the most obvious RDB to EObject
mapping solution...
> Brian
>
Re: help with existing meta data repository mapping [message #383879 is a reply to message #383878] Tue, 13 January 2009 03:30 Go to previous messageGo to next message
Eclipse User
Originally posted by: brian.silberbauer.gmail.com

On Mon, 12 Jan 2009 20:08:20 -0500, Ed Merks wrote:

Thanks for the reply Ed, more comments below..

> Brian,
>
> Comments below.
>
> Most of the Eclipse modeling stack of technology is built around Ecore
> as the core meta model. So much of your question about mapping is how
> to map whatever meta model/information you have to Ecore...

OK, that clears that up nicely, what confuses me is that I thought ecore
was java specific, but it seems uml2 extends ecore??

>> Possibilities we've seen so far would be to map to EMF by either
>> exporting portions to XMI and importing that, generating the EMF code
>> directly from the repository or creating a custom CDO implementation.
>>
> It's "something" -> XMI -> "instance of an Ecore model" sounds like a
> level on indirection you shouldn't need. We can only read XMI because
> there is an Ecore model onto which the elements and attributes map. So
> if you can map "something" to XMI then you can map "something" directly
> onto an instance (an EObject). Things like Teneo and CDO (and JCRM for
> that matter) can help help bridge the gap between a repository and
> EObject instances.

The XMI route is one I wouldn't want to go down, so good to hear I
shouldn't have to.

>> Any help, comments would be appreciated, I'm in acronym overload.
>>
> Yes, that sucks. But to give concrete advice, I think we need more
> information than that you have a "format in RDB". After all that's
> just an acronym to add to the soup. My knee jerk response would be to
> say that Hibernate helps map RDB to Java objects and Teneo provides
> integration with Hibernate and hence is the most obvious RDB to EObject
> mapping solution...
>> Brian
>>

Well, this is an old project that I'm taking over and I am bound by an
NDA, so I'm going to be cryptic with the information I give out and I
don't have direct access to the previous developers so there are still a
few black holes in my knowledge of the system.

We end up with node data stored in a single self referencing table in a
database. I'd like to be able to map this data into EMF and query it,
merge/compare it and visually manipulate it. I'm waiting for full
explanation of the columns, but it basically holds the node information
(with types etc) and the relationships between nodes. It also holds a
basic parent child relationship as well.

At this stage I'm hoping EMF can help me out, I've created some
structures pragmatically using the uml2 library , used draw2d to create
some diagrams and am looking into GEF which looks great and just started
reading up on ecore tools.

thanks again Ed.
Re: help with existing meta data repository mapping [message #383880 is a reply to message #383876] Tue, 13 January 2009 06:32 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad Varnica
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Hi Brian,

Did you try to use Dali ?
This could import your databases inside Eclipse 3.4.
I have written a short modeling documentation on this subject at:
http://www.forum-omondo.com/documentation_eclipseuml_2008/Ec lipse_Database/Reverse_Existing_Database/index.html

Please note that you can user dali without EclipseUML 2008. In this
example EclipseUML is just used as UML Editor for JPA annotations.
Dali is a great project and because it is an Eclipse plugin you can use
any other Eclipse plugin to expand Dali as a beautifier :-)

Vlad
Omondo
Re: help with existing meta data repository mapping [message #383881 is a reply to message #383879] Tue, 13 January 2009 06:48 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050107040101090709030006
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Brian,

Comments below.

Brian Silberbauer wrote:
> On Mon, 12 Jan 2009 20:08:20 -0500, Ed Merks wrote:
>
> Thanks for the reply Ed, more comments below..
>
>
>> Brian,
>>
>> Comments below.
>>
>> Most of the Eclipse modeling stack of technology is built around Ecore
>> as the core meta model. So much of your question about mapping is how
>> to map whatever meta model/information you have to Ecore...
>>
>
> OK, that clears that up nicely, what confuses me is that I thought ecore
> was java specific, but it seems uml2 extends ecore??
>
Ecore is effectively isomorphic to the OMG's EMOF but it's fair to say
we've added some things to Ecore that aren't in EMOF and that are Java
specific. UML2 extending Ecore is an implementation artifact that has
no real semantic significance and has always annoyed me. It was done
simply to inherit the ability to use EAnnotations on all UML Elements,
rather than defining an analogous concept in UML itself.
>
>>> Possibilities we've seen so far would be to map to EMF by either
>>> exporting portions to XMI and importing that, generating the EMF code
>>> directly from the repository or creating a custom CDO implementation.
>>>
>>>
>> It's "something" -> XMI -> "instance of an Ecore model" sounds like a
>> level on indirection you shouldn't need. We can only read XMI because
>> there is an Ecore model onto which the elements and attributes map. So
>> if you can map "something" to XMI then you can map "something" directly
>> onto an instance (an EObject). Things like Teneo and CDO (and JCRM for
>> that matter) can help help bridge the gap between a repository and
>> EObject instances.
>>
>
> The XMI route is one I wouldn't want to go down, so good to hear I
> shouldn't have to.
>
>
>>> Any help, comments would be appreciated, I'm in acronym overload.
>>>
>>>
>> Yes, that sucks. But to give concrete advice, I think we need more
>> information than that you have a "format in RDB". After all that's
>> just an acronym to add to the soup. My knee jerk response would be to
>> say that Hibernate helps map RDB to Java objects and Teneo provides
>> integration with Hibernate and hence is the most obvious RDB to EObject
>> mapping solution...
>>
>>> Brian
>>>
>>>
>
> Well, this is an old project that I'm taking over and I am bound by an
> NDA, so I'm going to be cryptic with the information I give out and I
> don't have direct access to the previous developers so there are still a
> few black holes in my knowledge of the system.
>
Oh joy. Hopefully you're well paid. :-)
> We end up with node data stored in a single self referencing table in a
> database. I'd like to be able to map this data into EMF and query it,
> merge/compare it and visually manipulate it. I'm waiting for full
> explanation of the columns, but it basically holds the node information
> (with types etc) and the relationships between nodes. It also holds a
> basic parent child relationship as well.
>
It sounds slightly gross. :-P I suppose you're want to continue to read
and write exactly this format, rather than import from it and then
migrate to a perhaps nicer format?
> At this stage I'm hoping EMF can help me out, I've created some
> structures pragmatically using the uml2 library , used draw2d to create
> some diagrams and am looking into GEF which looks great and just started
> reading up on ecore tools.
>
There is certainly a wealth of technology available. If you're using
UML basically just for class diagrams to describe data structures,
probably Ecore along with Ecore Tools will be sufficient... Of course
there is two way mapping between UML and Ecore, so that's useful as well...
> thanks again Ed.
>

--------------050107040101090709030006
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Brian,<br>
<br>
Comments below.<br>
<br>
Brian Silberbauer wrote:
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">On Mon, 12 Jan 2009 20:08:20 -0500, Ed Merks wrote:

Thanks for the reply Ed, more comments below..

</pre>
<blockquote type="cite">
<pre wrap="">Brian,

Comments below.

Most of the Eclipse modeling stack of technology is built around Ecore
as the core meta model. So much of your question about mapping is how
to map whatever meta model/information you have to Ecore...
</pre>
</blockquote>
<pre wrap=""><!---->
OK, that clears that up nicely, what confuses me is that I thought ecore
was java specific, but it seems uml2 extends ecore??
</pre>
</blockquote>
Ecore is effectively isomorphic to the OMG's EMOF but it's fair to say
we've added some things to Ecore that aren't in EMOF and that are Java
specific.  UML2 extending Ecore is an implementation artifact that has
no real semantic significance and has always annoyed me.  It was done
simply to inherit the ability to use EAnnotations on all UML Elements,
rather than defining an analogous concept in UML itself.<br>
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Possibilities we've seen so far would be to map to EMF by either
exporting portions to XMI and importing that, generating the EMF code
directly from the repository or creating a custom CDO implementation.

</pre>
</blockquote>
<pre wrap="">It's "something" -&gt; XMI -&gt; "instance of an Ecore model" sounds like a
level on indirection you shouldn't need. We can only read XMI because
there is an Ecore model onto which the elements and attributes map. So
if you can map "something" to XMI then you can map "something" directly
onto an instance (an EObject). Things like Teneo and CDO (and JCRM for
that matter) can help help bridge the gap between a repository and
EObject instances.
</pre>
</blockquote>
<pre wrap=""><!---->
The XMI route is one I wouldn't want to go down, so good to hear I
shouldn't have to.

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Any help, comments would be appreciated, I'm in acronym overload.

</pre>
</blockquote>
<pre wrap="">Yes, that sucks. But to give concrete advice, I think we need more
information than that you have a "format in RDB". After all that's
just an acronym to add to the soup. My knee jerk response would be to
say that Hibernate helps map RDB to Java objects and Teneo provides
integration with Hibernate and hence is the most obvious RDB to EObject
mapping solution...
</pre>
<blockquote type="cite">
<pre wrap="">Brian

</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
Well, this is an old project that I'm taking over and I am bound by an
NDA, so I'm going to be cryptic with the information I give out and I
don't have direct access to the previous developers so there are still a
few black holes in my knowledge of the system.
</pre>
</blockquote>
Oh joy.  Hopefully you're well paid. :-)<br>
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">
We end up with node data stored in a single self referencing table in a
database. I'd like to be able to map this data into EMF and query it,
merge/compare it and visually manipulate it. I'm waiting for full
explanation of the columns, but it basically holds the node information
(with types etc) and the relationships between nodes. It also holds a
basic parent child relationship as well.
</pre>
</blockquote>
It sounds slightly gross. :-P  I suppose you're want to continue to
read and write exactly this format, rather than import from it and then
migrate to a perhaps nicer format?<br>
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">
At this stage I'm hoping EMF can help me out, I've created some
structures pragmatically using the uml2 library , used draw2d to create
some diagrams and am looking into GEF which looks great and just started
reading up on ecore tools.
</pre>
</blockquote>
There is certainly a wealth of technology available.  If you're using
UML basically just for class diagrams to describe data structures,
probably Ecore along with Ecore Tools will be sufficient...  Of course
there is two way mapping between UML and Ecore, so that's useful as
well...<br>
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">
thanks again Ed.
</pre>
</blockquote>
</body>
</html>

--------------050107040101090709030006--
Re: help with existing meta data repository mapping [message #383882 is a reply to message #383881] Tue, 13 January 2009 08:37 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Ed, Brian,

-----8<-----

> There is certainly a wealth of technology available. If you're using
> UML basically just for class diagrams to describe data structures,
> probably Ecore along with Ecore Tools will be sufficient... Of course
> there is two way mapping between UML and Ecore, so that's useful as well...

This is where, IMO, the dependency of UML2 on Ecore introduces more
significant problems. The UML-based code generation is an extension of
Ecore's code generation, which implies the need to map UML metamodels to
Ecore. Unfortunately, this is a lossy mapping because UML simply has
more capabilities than EMOF.

For example, in UML, data types can define attributes and operations,
whereas in EMOF (hence Ecore) they cannot. This results in UML
transforming DataTypes to EClasses, which gives them object semantics
that they aren't intended to have. OCL (the spec and the MDT
implementation) solves this problem by creating companion EClasses to
the EDataTypes, to own the attributes and operations for them. (ugh)

Generalization is another semantic disconnect: in UML, DataTypes can
define subtyping relationships, but DataTypes in EMOF (and, hence, Ecore
EDataTypes) cannot. OCL doesn't have an answer to that, and it's a
darned nuisance. :-(

I wonder what it would take to refactor the EMF code generation
framework (and UML2) to provide code generation and run-time support for
"native" UML metamodels, in addition to Ecore? ;-)
Re: help with existing meta data repository mapping [message #383883 is a reply to message #383882] Tue, 13 January 2009 13:58 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Christian,

I wouldn't hold my breath while waiting! :-P


Christian W. Damus wrote:
> Hi, Ed, Brian,
>
> -----8<-----
>
>> There is certainly a wealth of technology available. If you're using
>> UML basically just for class diagrams to describe data structures,
>> probably Ecore along with Ecore Tools will be sufficient... Of
>> course there is two way mapping between UML and Ecore, so that's
>> useful as well...
>
> This is where, IMO, the dependency of UML2 on Ecore introduces more
> significant problems. The UML-based code generation is an extension
> of Ecore's code generation, which implies the need to map UML
> metamodels to Ecore. Unfortunately, this is a lossy mapping because
> UML simply has more capabilities than EMOF.
>
> For example, in UML, data types can define attributes and operations,
> whereas in EMOF (hence Ecore) they cannot. This results in UML
> transforming DataTypes to EClasses, which gives them object semantics
> that they aren't intended to have. OCL (the spec and the MDT
> implementation) solves this problem by creating companion EClasses to
> the EDataTypes, to own the attributes and operations for them. (ugh)
>
> Generalization is another semantic disconnect: in UML, DataTypes can
> define subtyping relationships, but DataTypes in EMOF (and, hence,
> Ecore EDataTypes) cannot. OCL doesn't have an answer to that, and
> it's a darned nuisance. :-(
>
> I wonder what it would take to refactor the EMF code generation
> framework (and UML2) to provide code generation and run-time support
> for "native" UML metamodels, in addition to Ecore? ;-)
Re: help with existing meta data repository mapping [message #383884 is a reply to message #383880] Wed, 14 January 2009 01:42 Go to previous messageGo to next message
Eclipse User
Originally posted by: brian.silberbauer.gmail.com

Hi Vlad

Dali seems to be more database entity mapping related, I have some meta
data from a system stored in a database.

Thanks for the link anyway, looks interesting.

Brian


On Tue, 13 Jan 2009 11:32:03 +0000, Vlad Varnica wrote:

> Hi Brian,
>
> Did you try to use Dali ?
> This could import your databases inside Eclipse 3.4. I have written a
> short modeling documentation on this subject at:
> http://www.forum-omondo.com/documentation_eclipseuml_2008/
Eclipse_Database/Reverse_Existing_Database/index.html
>
> Please note that you can user dali without EclipseUML 2008. In this
> example EclipseUML is just used as UML Editor for JPA annotations. Dali
> is a great project and because it is an Eclipse plugin you can use any
> other Eclipse plugin to expand Dali as a beautifier :-)
>
> Vlad
> Omondo
Re: help with existing meta data repository mapping [message #383885 is a reply to message #383881] Wed, 14 January 2009 01:51 Go to previous messageGo to next message
Eclipse User
Originally posted by: brian.silberbauer.gmail.com

On Tue, 13 Jan 2009 06:48:10 -0500, Ed Merks wrote:

<snip>
>> Well, this is an old project that I'm taking over and I am bound by an
>> NDA, so I'm going to be cryptic with the information I give out and I
>> don't have direct access to the previous developers so there are still
>> a few black holes in my knowledge of the system.
>>
> Oh joy. Hopefully you're well paid. :-)

by the hour :)

>> We end up with node data stored in a single self referencing table in a
>> database. I'd like to be able to map this data into EMF and query it,
>> merge/compare it and visually manipulate it. I'm waiting for full
>> explanation of the columns, but it basically holds the node information
>> (with types etc) and the relationships between nodes. It also holds a
>> basic parent child relationship as well.
>>
> It sounds slightly gross. :-P I suppose you're want to continue to read
> and write exactly this format, rather than import from it and then
> migrate to a perhaps nicer format?

Did I mention the database was 20Gb? That aside, converting it to another
format is a possibility, might be the easiest way forward right now.

>> At this stage I'm hoping EMF can help me out, I've created some
>> structures pragmatically using the uml2 library , used draw2d to create
>> some diagrams and am looking into GEF which looks great and just
>> started reading up on ecore tools.
>>
> There is certainly a wealth of technology available. If you're using
> UML basically just for class diagrams to describe data structures,
> probably Ecore along with Ecore Tools will be sufficient... Of course
> there is two way mapping between UML and Ecore, so that's useful as
> well...

It all comes down to how customizable Ecore Tools is. Due to the size of
the meta data I would like to know whether Ecore Tools could load only
the data we are viewing, not the whole tree.
Re: help with existing meta data repository mapping [message #383886 is a reply to message #383884] Wed, 14 January 2009 04:51 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad Varnica
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Brian,

I think you have two possible solutions. I mean either import into EMF and
use all EMF and related plugins, or import it in your java code and then
reverse engineer your code in order to create a UML 2.2 model (directly
without EMF transformation).
I don't know if you can import all information using Dali but you should
try and even extend the current reverse mechanism which is open source.

What is important is to consider is the quality of the extracted
information and how to load it into an EMF model or into an UML 2.2 model.
Good luck for your project :-)

Vlad,
Re: help with existing meta data repository mapping [message #383887 is a reply to message #383885] Wed, 14 January 2009 08:48 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030802080008080001010000
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Brian,

Comments below.

Brian Silberbauer wrote:
> On Tue, 13 Jan 2009 06:48:10 -0500, Ed Merks wrote:
>
> <snip>
>
>>> Well, this is an old project that I'm taking over and I am bound by an
>>> NDA, so I'm going to be cryptic with the information I give out and I
>>> don't have direct access to the previous developers so there are still
>>> a few black holes in my knowledge of the system.
>>>
>>>
>> Oh joy. Hopefully you're well paid. :-)
>>
>
> by the hour :)
>
>
>>> We end up with node data stored in a single self referencing table in a
>>> database. I'd like to be able to map this data into EMF and query it,
>>> merge/compare it and visually manipulate it. I'm waiting for full
>>> explanation of the columns, but it basically holds the node information
>>> (with types etc) and the relationships between nodes. It also holds a
>>> basic parent child relationship as well.
>>>
>>>
>> It sounds slightly gross. :-P I suppose you're want to continue to read
>> and write exactly this format, rather than import from it and then
>> migrate to a perhaps nicer format?
>>
>
> Did I mention the database was 20Gb? That aside, converting it to another
> format is a possibility, might be the easiest way forward right now.
>
Certainly keep it in mind... A representation not tuned for the way it
needs to be used will tend to be an ongoing source of problems...
>
>>> At this stage I'm hoping EMF can help me out, I've created some
>>> structures pragmatically using the uml2 library , used draw2d to create
>>> some diagrams and am looking into GEF which looks great and just
>>> started reading up on ecore tools.
>>>
>>>
>> There is certainly a wealth of technology available. If you're using
>> UML basically just for class diagrams to describe data structures,
>> probably Ecore along with Ecore Tools will be sufficient... Of course
>> there is two way mapping between UML and Ecore, so that's useful as
>> well...
>>
>
> It all comes down to how customizable Ecore Tools is. Due to the size of
> the meta data I would like to know whether Ecore Tools could load only
> the data we are viewing, not the whole tree.
>
Given the bloated nature of UML, certainly an Ecore representation will
take a lot less space than a UML representation of the same information;
both use the same Notation model for the graphical representation. None
of the editors is terribly good at dealing with things smaller than a
single resource.

CDO is doing some interesting things in this regard though

http://thegordian.blogspot.com/2008/11/how-scalable-are-my-m odels.html

And we're working on improving the basic footprint, which will benefit
any model that chooses to use it (including Ecore, UML2, and the
Notation model):

https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501


>
>

--------------030802080008080001010000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Brian,<br>
<br>
Comments below.<br>
<br>
Brian Silberbauer wrote:
<blockquote cite="mid:gkk223$b91$2@build.eclipse.org" type="cite">
<pre wrap="">On Tue, 13 Jan 2009 06:48:10 -0500, Ed Merks wrote:

&lt;snip&gt;
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Well, this is an old project that I'm taking over and I am bound by an
NDA, so I'm going to be cryptic with the information I give out and I
don't have direct access to the previous developers so there are still
a few black holes in my knowledge of the system.

</pre>
</blockquote>
<pre wrap="">Oh joy. Hopefully you're well paid. :-)
</pre>
</blockquote>
<pre wrap=""><!---->
by the hour :)

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We end up with node data stored in a single self referencing table in a
database. I'd like to be able to map this data into EMF and query it,
merge/compare it and visually manipulate it. I'm waiting for full
explanation of the columns, but it basically holds the node information
(with types etc) and the relationships between nodes. It also holds a
basic parent child relationship as well.

</pre>
</blockquote>
<pre wrap="">It sounds slightly gross. :-P I suppose you're want to continue to read
and write exactly this format, rather than import from it and then
migrate to a perhaps nicer format?
</pre>
</blockquote>
<pre wrap=""><!---->
Did I mention the database was 20Gb? That aside, converting it to another
format is a possibility, might be the easiest way forward right now.
</pre>
</blockquote>
Certainly keep it in mind...  A representation not tuned for the way it
needs to be used will tend to be an ongoing source of problems...<br>
<blockquote cite="mid:gkk223$b91$2@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">At this stage I'm hoping EMF can help me out, I've created some
structures pragmatically using the uml2 library , used draw2d to create
some diagrams and am looking into GEF which looks great and just
started reading up on ecore tools.

</pre>
</blockquote>
<pre wrap="">There is certainly a wealth of technology available. If you're using
UML basically just for class diagrams to describe data structures,
probably Ecore along with Ecore Tools will be sufficient... Of course
there is two way mapping between UML and Ecore, so that's useful as
well...
</pre>
</blockquote>
<pre wrap=""><!---->
It all comes down to how customizable Ecore Tools is. Due to the size of
the meta data I would like to know whether Ecore Tools could load only
the data we are viewing, not the whole tree.
</pre>
</blockquote>
Given the bloated nature of UML, certainly an Ecore representation will
take a lot less space than a UML representation of the same
information; both use the same Notation model for the graphical
representation.  None of the editors is terribly good at dealing with
things smaller than a single resource.  <br>
<br>
CDO is doing some interesting things in this regard though<br>
<blockquote><a
href=" http://thegordian.blogspot.com/2008/11/how-scalable-are-my-m odels.html"> http://thegordian.blogspot.com/2008/11/how-scalable-are-my-m odels.html</a><br>
</blockquote>
And we're working on improving the basic footprint, which will benefit
any model that chooses to use it (including Ecore, UML2, and the
Notation model):<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501">https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501</a><br>
</blockquote>
<br>
<blockquote cite="mid:gkk223$b91$2@build.eclipse.org" type="cite">
<pre wrap="">

</pre>
</blockquote>
</body>
</html>

--------------030802080008080001010000--
Re: help with existing meta data repository mapping [message #613828 is a reply to message #383876] Mon, 12 January 2009 20:08 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Brian,

Comments below.

Brian Silberbauer wrote:
> Hi all
>
> I'm new to the eclipse modelling world and there is a lot of new concepts
> and libraries and plugins, so I hope I'm posting at the right place:
>
Modeling is usually not the right place, because it's just a general
catch-all for the top-level modeling project...
> I have a client who has an existing application extracting meta
> information from various sources and storing it in a propriety format in
> a RDB and can view it through a custom built viewer.
>
> We would like to be able to use the visualization tools and query tools
> available on the existing meta data repository, what would you recommend
> the best way to create this mapping?
>
This is certainly a very general question, so it does seem reasonable to
ask it here...

Most of the Eclipse modeling stack of technology is built around Ecore
as the core meta model. So much of your question about mapping is how
to map whatever meta model/information you have to Ecore...
> Possibilities we've seen so far would be to map to EMF by either
> exporting portions to XMI and importing that, generating the EMF code
> directly from the repository or creating a custom CDO implementation.
>
It's "something" -> XMI -> "instance of an Ecore model" sounds like a
level on indirection you shouldn't need. We can only read XMI because
there is an Ecore model onto which the elements and attributes map. So
if you can map "something" to XMI then you can map "something" directly
onto an instance (an EObject). Things like Teneo and CDO (and JCRM for
that matter) can help help bridge the gap between a repository and
EObject instances.
> Any help, comments would be appreciated, I'm in acronym overload.
>
Yes, that sucks. But to give concrete advice, I think we need more
information than that you have a "format in RDB". After all that's
just an acronym to add to the soup. My knee jerk response would be to
say that Hibernate helps map RDB to Java objects and Teneo provides
integration with Hibernate and hence is the most obvious RDB to EObject
mapping solution...
> Brian
>
Re: help with existing meta data repository mapping [message #613830 is a reply to message #383878] Tue, 13 January 2009 03:30 Go to previous message
Eclipse User
Originally posted by: brian.silberbauer.gmail.com

On Mon, 12 Jan 2009 20:08:20 -0500, Ed Merks wrote:

Thanks for the reply Ed, more comments below..

> Brian,
>
> Comments below.
>
> Most of the Eclipse modeling stack of technology is built around Ecore
> as the core meta model. So much of your question about mapping is how
> to map whatever meta model/information you have to Ecore...

OK, that clears that up nicely, what confuses me is that I thought ecore
was java specific, but it seems uml2 extends ecore??

>> Possibilities we've seen so far would be to map to EMF by either
>> exporting portions to XMI and importing that, generating the EMF code
>> directly from the repository or creating a custom CDO implementation.
>>
> It's "something" -> XMI -> "instance of an Ecore model" sounds like a
> level on indirection you shouldn't need. We can only read XMI because
> there is an Ecore model onto which the elements and attributes map. So
> if you can map "something" to XMI then you can map "something" directly
> onto an instance (an EObject). Things like Teneo and CDO (and JCRM for
> that matter) can help help bridge the gap between a repository and
> EObject instances.

The XMI route is one I wouldn't want to go down, so good to hear I
shouldn't have to.

>> Any help, comments would be appreciated, I'm in acronym overload.
>>
> Yes, that sucks. But to give concrete advice, I think we need more
> information than that you have a "format in RDB". After all that's
> just an acronym to add to the soup. My knee jerk response would be to
> say that Hibernate helps map RDB to Java objects and Teneo provides
> integration with Hibernate and hence is the most obvious RDB to EObject
> mapping solution...
>> Brian
>>

Well, this is an old project that I'm taking over and I am bound by an
NDA, so I'm going to be cryptic with the information I give out and I
don't have direct access to the previous developers so there are still a
few black holes in my knowledge of the system.

We end up with node data stored in a single self referencing table in a
database. I'd like to be able to map this data into EMF and query it,
merge/compare it and visually manipulate it. I'm waiting for full
explanation of the columns, but it basically holds the node information
(with types etc) and the relationships between nodes. It also holds a
basic parent child relationship as well.

At this stage I'm hoping EMF can help me out, I've created some
structures pragmatically using the uml2 library , used draw2d to create
some diagrams and am looking into GEF which looks great and just started
reading up on ecore tools.

thanks again Ed.
Re: help with existing meta data repository mapping [message #613832 is a reply to message #383876] Tue, 13 January 2009 06:32 Go to previous message
Vlad Varnica is currently offline Vlad Varnica
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Hi Brian,

Did you try to use Dali ?
This could import your databases inside Eclipse 3.4.
I have written a short modeling documentation on this subject at:
http://www.forum-omondo.com/documentation_eclipseuml_2008/Ec lipse_Database/Reverse_Existing_Database/index.html

Please note that you can user dali without EclipseUML 2008. In this
example EclipseUML is just used as UML Editor for JPA annotations.
Dali is a great project and because it is an Eclipse plugin you can use
any other Eclipse plugin to expand Dali as a beautifier :-)

Vlad
Omondo
Re: help with existing meta data repository mapping [message #613834 is a reply to message #383879] Tue, 13 January 2009 06:48 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050107040101090709030006
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Brian,

Comments below.

Brian Silberbauer wrote:
> On Mon, 12 Jan 2009 20:08:20 -0500, Ed Merks wrote:
>
> Thanks for the reply Ed, more comments below..
>
>
>> Brian,
>>
>> Comments below.
>>
>> Most of the Eclipse modeling stack of technology is built around Ecore
>> as the core meta model. So much of your question about mapping is how
>> to map whatever meta model/information you have to Ecore...
>>
>
> OK, that clears that up nicely, what confuses me is that I thought ecore
> was java specific, but it seems uml2 extends ecore??
>
Ecore is effectively isomorphic to the OMG's EMOF but it's fair to say
we've added some things to Ecore that aren't in EMOF and that are Java
specific. UML2 extending Ecore is an implementation artifact that has
no real semantic significance and has always annoyed me. It was done
simply to inherit the ability to use EAnnotations on all UML Elements,
rather than defining an analogous concept in UML itself.
>
>>> Possibilities we've seen so far would be to map to EMF by either
>>> exporting portions to XMI and importing that, generating the EMF code
>>> directly from the repository or creating a custom CDO implementation.
>>>
>>>
>> It's "something" -> XMI -> "instance of an Ecore model" sounds like a
>> level on indirection you shouldn't need. We can only read XMI because
>> there is an Ecore model onto which the elements and attributes map. So
>> if you can map "something" to XMI then you can map "something" directly
>> onto an instance (an EObject). Things like Teneo and CDO (and JCRM for
>> that matter) can help help bridge the gap between a repository and
>> EObject instances.
>>
>
> The XMI route is one I wouldn't want to go down, so good to hear I
> shouldn't have to.
>
>
>>> Any help, comments would be appreciated, I'm in acronym overload.
>>>
>>>
>> Yes, that sucks. But to give concrete advice, I think we need more
>> information than that you have a "format in RDB". After all that's
>> just an acronym to add to the soup. My knee jerk response would be to
>> say that Hibernate helps map RDB to Java objects and Teneo provides
>> integration with Hibernate and hence is the most obvious RDB to EObject
>> mapping solution...
>>
>>> Brian
>>>
>>>
>
> Well, this is an old project that I'm taking over and I am bound by an
> NDA, so I'm going to be cryptic with the information I give out and I
> don't have direct access to the previous developers so there are still a
> few black holes in my knowledge of the system.
>
Oh joy. Hopefully you're well paid. :-)
> We end up with node data stored in a single self referencing table in a
> database. I'd like to be able to map this data into EMF and query it,
> merge/compare it and visually manipulate it. I'm waiting for full
> explanation of the columns, but it basically holds the node information
> (with types etc) and the relationships between nodes. It also holds a
> basic parent child relationship as well.
>
It sounds slightly gross. :-P I suppose you're want to continue to read
and write exactly this format, rather than import from it and then
migrate to a perhaps nicer format?
> At this stage I'm hoping EMF can help me out, I've created some
> structures pragmatically using the uml2 library , used draw2d to create
> some diagrams and am looking into GEF which looks great and just started
> reading up on ecore tools.
>
There is certainly a wealth of technology available. If you're using
UML basically just for class diagrams to describe data structures,
probably Ecore along with Ecore Tools will be sufficient... Of course
there is two way mapping between UML and Ecore, so that's useful as well...
> thanks again Ed.
>

--------------050107040101090709030006
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Brian,<br>
<br>
Comments below.<br>
<br>
Brian Silberbauer wrote:
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">On Mon, 12 Jan 2009 20:08:20 -0500, Ed Merks wrote:

Thanks for the reply Ed, more comments below..

</pre>
<blockquote type="cite">
<pre wrap="">Brian,

Comments below.

Most of the Eclipse modeling stack of technology is built around Ecore
as the core meta model. So much of your question about mapping is how
to map whatever meta model/information you have to Ecore...
</pre>
</blockquote>
<pre wrap=""><!---->
OK, that clears that up nicely, what confuses me is that I thought ecore
was java specific, but it seems uml2 extends ecore??
</pre>
</blockquote>
Ecore is effectively isomorphic to the OMG's EMOF but it's fair to say
we've added some things to Ecore that aren't in EMOF and that are Java
specific.  UML2 extending Ecore is an implementation artifact that has
no real semantic significance and has always annoyed me.  It was done
simply to inherit the ability to use EAnnotations on all UML Elements,
rather than defining an analogous concept in UML itself.<br>
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Possibilities we've seen so far would be to map to EMF by either
exporting portions to XMI and importing that, generating the EMF code
directly from the repository or creating a custom CDO implementation.

</pre>
</blockquote>
<pre wrap="">It's "something" -&gt; XMI -&gt; "instance of an Ecore model" sounds like a
level on indirection you shouldn't need. We can only read XMI because
there is an Ecore model onto which the elements and attributes map. So
if you can map "something" to XMI then you can map "something" directly
onto an instance (an EObject). Things like Teneo and CDO (and JCRM for
that matter) can help help bridge the gap between a repository and
EObject instances.
</pre>
</blockquote>
<pre wrap=""><!---->
The XMI route is one I wouldn't want to go down, so good to hear I
shouldn't have to.

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Any help, comments would be appreciated, I'm in acronym overload.

</pre>
</blockquote>
<pre wrap="">Yes, that sucks. But to give concrete advice, I think we need more
information than that you have a "format in RDB". After all that's
just an acronym to add to the soup. My knee jerk response would be to
say that Hibernate helps map RDB to Java objects and Teneo provides
integration with Hibernate and hence is the most obvious RDB to EObject
mapping solution...
</pre>
<blockquote type="cite">
<pre wrap="">Brian

</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
Well, this is an old project that I'm taking over and I am bound by an
NDA, so I'm going to be cryptic with the information I give out and I
don't have direct access to the previous developers so there are still a
few black holes in my knowledge of the system.
</pre>
</blockquote>
Oh joy.  Hopefully you're well paid. :-)<br>
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">
We end up with node data stored in a single self referencing table in a
database. I'd like to be able to map this data into EMF and query it,
merge/compare it and visually manipulate it. I'm waiting for full
explanation of the columns, but it basically holds the node information
(with types etc) and the relationships between nodes. It also holds a
basic parent child relationship as well.
</pre>
</blockquote>
It sounds slightly gross. :-P  I suppose you're want to continue to
read and write exactly this format, rather than import from it and then
migrate to a perhaps nicer format?<br>
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">
At this stage I'm hoping EMF can help me out, I've created some
structures pragmatically using the uml2 library , used draw2d to create
some diagrams and am looking into GEF which looks great and just started
reading up on ecore tools.
</pre>
</blockquote>
There is certainly a wealth of technology available.  If you're using
UML basically just for class diagrams to describe data structures,
probably Ecore along with Ecore Tools will be sufficient...  Of course
there is two way mapping between UML and Ecore, so that's useful as
well...<br>
<blockquote cite="mid:gkhjet$bnq$1@build.eclipse.org" type="cite">
<pre wrap="">
thanks again Ed.
</pre>
</blockquote>
</body>
</html>

--------------050107040101090709030006--
Re: help with existing meta data repository mapping [message #613836 is a reply to message #383881] Tue, 13 January 2009 08:37 Go to previous message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Ed, Brian,

-----8<-----

> There is certainly a wealth of technology available. If you're using
> UML basically just for class diagrams to describe data structures,
> probably Ecore along with Ecore Tools will be sufficient... Of course
> there is two way mapping between UML and Ecore, so that's useful as well...

This is where, IMO, the dependency of UML2 on Ecore introduces more
significant problems. The UML-based code generation is an extension of
Ecore's code generation, which implies the need to map UML metamodels to
Ecore. Unfortunately, this is a lossy mapping because UML simply has
more capabilities than EMOF.

For example, in UML, data types can define attributes and operations,
whereas in EMOF (hence Ecore) they cannot. This results in UML
transforming DataTypes to EClasses, which gives them object semantics
that they aren't intended to have. OCL (the spec and the MDT
implementation) solves this problem by creating companion EClasses to
the EDataTypes, to own the attributes and operations for them. (ugh)

Generalization is another semantic disconnect: in UML, DataTypes can
define subtyping relationships, but DataTypes in EMOF (and, hence, Ecore
EDataTypes) cannot. OCL doesn't have an answer to that, and it's a
darned nuisance. :-(

I wonder what it would take to refactor the EMF code generation
framework (and UML2) to provide code generation and run-time support for
"native" UML metamodels, in addition to Ecore? ;-)
Re: help with existing meta data repository mapping [message #613838 is a reply to message #383882] Tue, 13 January 2009 13:58 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Christian,

I wouldn't hold my breath while waiting! :-P


Christian W. Damus wrote:
> Hi, Ed, Brian,
>
> -----8<-----
>
>> There is certainly a wealth of technology available. If you're using
>> UML basically just for class diagrams to describe data structures,
>> probably Ecore along with Ecore Tools will be sufficient... Of
>> course there is two way mapping between UML and Ecore, so that's
>> useful as well...
>
> This is where, IMO, the dependency of UML2 on Ecore introduces more
> significant problems. The UML-based code generation is an extension
> of Ecore's code generation, which implies the need to map UML
> metamodels to Ecore. Unfortunately, this is a lossy mapping because
> UML simply has more capabilities than EMOF.
>
> For example, in UML, data types can define attributes and operations,
> whereas in EMOF (hence Ecore) they cannot. This results in UML
> transforming DataTypes to EClasses, which gives them object semantics
> that they aren't intended to have. OCL (the spec and the MDT
> implementation) solves this problem by creating companion EClasses to
> the EDataTypes, to own the attributes and operations for them. (ugh)
>
> Generalization is another semantic disconnect: in UML, DataTypes can
> define subtyping relationships, but DataTypes in EMOF (and, hence,
> Ecore EDataTypes) cannot. OCL doesn't have an answer to that, and
> it's a darned nuisance. :-(
>
> I wonder what it would take to refactor the EMF code generation
> framework (and UML2) to provide code generation and run-time support
> for "native" UML metamodels, in addition to Ecore? ;-)
Re: help with existing meta data repository mapping [message #613840 is a reply to message #383880] Wed, 14 January 2009 01:42 Go to previous message
Eclipse User
Originally posted by: brian.silberbauer.gmail.com

Hi Vlad

Dali seems to be more database entity mapping related, I have some meta
data from a system stored in a database.

Thanks for the link anyway, looks interesting.

Brian


On Tue, 13 Jan 2009 11:32:03 +0000, Vlad Varnica wrote:

> Hi Brian,
>
> Did you try to use Dali ?
> This could import your databases inside Eclipse 3.4. I have written a
> short modeling documentation on this subject at:
> http://www.forum-omondo.com/documentation_eclipseuml_2008/
Eclipse_Database/Reverse_Existing_Database/index.html
>
> Please note that you can user dali without EclipseUML 2008. In this
> example EclipseUML is just used as UML Editor for JPA annotations. Dali
> is a great project and because it is an Eclipse plugin you can use any
> other Eclipse plugin to expand Dali as a beautifier :-)
>
> Vlad
> Omondo
Re: help with existing meta data repository mapping [message #613842 is a reply to message #383881] Wed, 14 January 2009 01:51 Go to previous message
Eclipse User
Originally posted by: brian.silberbauer.gmail.com

On Tue, 13 Jan 2009 06:48:10 -0500, Ed Merks wrote:

<snip>
>> Well, this is an old project that I'm taking over and I am bound by an
>> NDA, so I'm going to be cryptic with the information I give out and I
>> don't have direct access to the previous developers so there are still
>> a few black holes in my knowledge of the system.
>>
> Oh joy. Hopefully you're well paid. :-)

by the hour :)

>> We end up with node data stored in a single self referencing table in a
>> database. I'd like to be able to map this data into EMF and query it,
>> merge/compare it and visually manipulate it. I'm waiting for full
>> explanation of the columns, but it basically holds the node information
>> (with types etc) and the relationships between nodes. It also holds a
>> basic parent child relationship as well.
>>
> It sounds slightly gross. :-P I suppose you're want to continue to read
> and write exactly this format, rather than import from it and then
> migrate to a perhaps nicer format?

Did I mention the database was 20Gb? That aside, converting it to another
format is a possibility, might be the easiest way forward right now.

>> At this stage I'm hoping EMF can help me out, I've created some
>> structures pragmatically using the uml2 library , used draw2d to create
>> some diagrams and am looking into GEF which looks great and just
>> started reading up on ecore tools.
>>
> There is certainly a wealth of technology available. If you're using
> UML basically just for class diagrams to describe data structures,
> probably Ecore along with Ecore Tools will be sufficient... Of course
> there is two way mapping between UML and Ecore, so that's useful as
> well...

It all comes down to how customizable Ecore Tools is. Due to the size of
the meta data I would like to know whether Ecore Tools could load only
the data we are viewing, not the whole tree.
Re: help with existing meta data repository mapping [message #613844 is a reply to message #383884] Wed, 14 January 2009 04:51 Go to previous message
Vlad Varnica is currently offline Vlad Varnica
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Brian,

I think you have two possible solutions. I mean either import into EMF and
use all EMF and related plugins, or import it in your java code and then
reverse engineer your code in order to create a UML 2.2 model (directly
without EMF transformation).
I don't know if you can import all information using Dali but you should
try and even extend the current reverse mechanism which is open source.

What is important is to consider is the quality of the extracted
information and how to load it into an EMF model or into an UML 2.2 model.
Good luck for your project :-)

Vlad,
Re: help with existing meta data repository mapping [message #613845 is a reply to message #383885] Wed, 14 January 2009 08:48 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030802080008080001010000
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Brian,

Comments below.

Brian Silberbauer wrote:
> On Tue, 13 Jan 2009 06:48:10 -0500, Ed Merks wrote:
>
> <snip>
>
>>> Well, this is an old project that I'm taking over and I am bound by an
>>> NDA, so I'm going to be cryptic with the information I give out and I
>>> don't have direct access to the previous developers so there are still
>>> a few black holes in my knowledge of the system.
>>>
>>>
>> Oh joy. Hopefully you're well paid. :-)
>>
>
> by the hour :)
>
>
>>> We end up with node data stored in a single self referencing table in a
>>> database. I'd like to be able to map this data into EMF and query it,
>>> merge/compare it and visually manipulate it. I'm waiting for full
>>> explanation of the columns, but it basically holds the node information
>>> (with types etc) and the relationships between nodes. It also holds a
>>> basic parent child relationship as well.
>>>
>>>
>> It sounds slightly gross. :-P I suppose you're want to continue to read
>> and write exactly this format, rather than import from it and then
>> migrate to a perhaps nicer format?
>>
>
> Did I mention the database was 20Gb? That aside, converting it to another
> format is a possibility, might be the easiest way forward right now.
>
Certainly keep it in mind... A representation not tuned for the way it
needs to be used will tend to be an ongoing source of problems...
>
>>> At this stage I'm hoping EMF can help me out, I've created some
>>> structures pragmatically using the uml2 library , used draw2d to create
>>> some diagrams and am looking into GEF which looks great and just
>>> started reading up on ecore tools.
>>>
>>>
>> There is certainly a wealth of technology available. If you're using
>> UML basically just for class diagrams to describe data structures,
>> probably Ecore along with Ecore Tools will be sufficient... Of course
>> there is two way mapping between UML and Ecore, so that's useful as
>> well...
>>
>
> It all comes down to how customizable Ecore Tools is. Due to the size of
> the meta data I would like to know whether Ecore Tools could load only
> the data we are viewing, not the whole tree.
>
Given the bloated nature of UML, certainly an Ecore representation will
take a lot less space than a UML representation of the same information;
both use the same Notation model for the graphical representation. None
of the editors is terribly good at dealing with things smaller than a
single resource.

CDO is doing some interesting things in this regard though

http://thegordian.blogspot.com/2008/11/how-scalable-are-my-m odels.html

And we're working on improving the basic footprint, which will benefit
any model that chooses to use it (including Ecore, UML2, and the
Notation model):

https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501


>
>

--------------030802080008080001010000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Brian,<br>
<br>
Comments below.<br>
<br>
Brian Silberbauer wrote:
<blockquote cite="mid:gkk223$b91$2@build.eclipse.org" type="cite">
<pre wrap="">On Tue, 13 Jan 2009 06:48:10 -0500, Ed Merks wrote:

&lt;snip&gt;
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Well, this is an old project that I'm taking over and I am bound by an
NDA, so I'm going to be cryptic with the information I give out and I
don't have direct access to the previous developers so there are still
a few black holes in my knowledge of the system.

</pre>
</blockquote>
<pre wrap="">Oh joy. Hopefully you're well paid. :-)
</pre>
</blockquote>
<pre wrap=""><!---->
by the hour :)

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We end up with node data stored in a single self referencing table in a
database. I'd like to be able to map this data into EMF and query it,
merge/compare it and visually manipulate it. I'm waiting for full
explanation of the columns, but it basically holds the node information
(with types etc) and the relationships between nodes. It also holds a
basic parent child relationship as well.

</pre>
</blockquote>
<pre wrap="">It sounds slightly gross. :-P I suppose you're want to continue to read
and write exactly this format, rather than import from it and then
migrate to a perhaps nicer format?
</pre>
</blockquote>
<pre wrap=""><!---->
Did I mention the database was 20Gb? That aside, converting it to another
format is a possibility, might be the easiest way forward right now.
</pre>
</blockquote>
Certainly keep it in mind...  A representation not tuned for the way it
needs to be used will tend to be an ongoing source of problems...<br>
<blockquote cite="mid:gkk223$b91$2@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">At this stage I'm hoping EMF can help me out, I've created some
structures pragmatically using the uml2 library , used draw2d to create
some diagrams and am looking into GEF which looks great and just
started reading up on ecore tools.

</pre>
</blockquote>
<pre wrap="">There is certainly a wealth of technology available. If you're using
UML basically just for class diagrams to describe data structures,
probably Ecore along with Ecore Tools will be sufficient... Of course
there is two way mapping between UML and Ecore, so that's useful as
well...
</pre>
</blockquote>
<pre wrap=""><!---->
It all comes down to how customizable Ecore Tools is. Due to the size of
the meta data I would like to know whether Ecore Tools could load only
the data we are viewing, not the whole tree.
</pre>
</blockquote>
Given the bloated nature of UML, certainly an Ecore representation will
take a lot less space than a UML representation of the same
information; both use the same Notation model for the graphical
representation.  None of the editors is terribly good at dealing with
things smaller than a single resource.  <br>
<br>
CDO is doing some interesting things in this regard though<br>
<blockquote><a
href=" http://thegordian.blogspot.com/2008/11/how-scalable-are-my-m odels.html"> http://thegordian.blogspot.com/2008/11/how-scalable-are-my-m odels.html</a><br>
</blockquote>
And we're working on improving the basic footprint, which will benefit
any model that chooses to use it (including Ecore, UML2, and the
Notation model):<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501">https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501</a><br>
</blockquote>
<br>
<blockquote cite="mid:gkk223$b91$2@build.eclipse.org" type="cite">
<pre wrap="">

</pre>
</blockquote>
</body>
</html>

--------------030802080008080001010000--
Previous Topic:help with existing meta data repository mapping
Next Topic:[Announce] Win a Copy of the EMF Book
Goto Forum:
  


Current Time: Thu Aug 21 06:26:05 EDT 2014

Powered by FUDForum. Page generated in 0.04221 seconds