Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Complex Model Relationships
Complex Model Relationships [message #631403] Thu, 07 October 2010 13:03 Go to next message
techteam is currently offline techteamFriend
Messages: 55
Registered: September 2010
Member
This is a multi-part message in MIME format.
--------------040809020006030904060005
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

First: Sorry for cross - post, but maybe somebody of the EMF experts can
help me at the abstract probem and for another point, I hope soneone of
the OCL experts can help me.



Outgoing from an old application and his datamodel , I want to rebuild
it with EMF.

Like the attached model, I have diffrent object types and all instances
of it can have bidirectional releations to other instances.
The problem here is that this relations not only simple but also I need
to hold informations about every relation.

For this problem I build an example based on:
- the example from Ed Merks at:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105920

- FeatureMap Example from the EMF book 2nd Edt

- my absolut minimal knowledge of OCL


At the moment, my first problem are, that if I try to get the
"related entities", I've got a NPE.
Inside the OCLinEcoreEdito gets the following:
(Here, I think my OCL code is wrong)

class AbstractEntity { abstract }
{
attribute datetimeLastChg : ecore_0::EDate[?];
attribute datetimeLastInfo : ecore_0::EDate[?];
property incommingRelations#relatedEntity : Relation[*] {
derived,transient,volatile,composes }
{
annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name
= 'entity', group = '#relations');
}
property outgoingRelations#entity : Relation[*] {
derived,transient,volatile,composes }
{
annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name
= 'relatedEntity', group = '#relations');
}
property relationedEntities#relatedEntities : AbstractEntity[*] {
readonly,derived,transient,volatile }
{
derivation: self.incommingRelations->collect(entity);
}
property relatedEntities#relationedEntities : AbstractEntity[*] {
readonly,derived,transient,volatile }
{
derivation: self.outgoingRelations->collect(relatedEntity);
}
attribute relations : ecore_0::EFeatureMapEntry[*]
{
annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(kind
= 'group');
}
}

How, I have to define, that I get all entities which are references
inside the collection of relation objects inside the AbstractEntity object?




The other question is more abstract:
The attatched model is a simplified example of my first draft.
But it shows my biggest problem what I have with, to define the
relations between the objects.

Had has somebody the same or similar problem to define such a complex
releationship and can point me, how can I do is in a better way?


Greetings

Heiko

--------------040809020006030904060005
Content-Type: text/xml;
name="RelationshipExample.ecore"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="RelationshipExample.ecore"

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="relationship"
nsURI="http://techteam.de/2010/relationshipExample" nsPrefix="rs">
<eAnnotations source="http://www.eclipse.org/emf/2002/Ecore">
<details key="invocationDelegates" value="http://www.eclipse.org/emf/2002/Ecore/OCL"/>
<details key="settingDelegates" value="http://www.eclipse.org/emf/2002/Ecore/OCL"/>
<details key="validationDelegates" value="http://www.eclipse.org/emf/2002/Ecore/OCL"/>
</eAnnotations>
<eClassifiers xsi:type="ecore:EClass" name="AbstractEntity" abstract="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="datetimeLastChg" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EDate"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="datetimeLastInfo" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EDate"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="incommingRelations" upperBound="-1"
eType="#//Relation" volatile="true" transient="true" derived="true" containment="true"
eOpposite="#//Relation/relatedEntity">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="entity"/>
<details key="group" value="#relations"/>
</eAnnotations>
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EReference" name="outgoingRelations" upperBound="-1"
eType="#//Relation" volatile="true" transient="true" derived="true" containment="true"
eOpposite="#//Relation/entity">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="relatedEntity"/>
<details key="group" value="#relations"/>
</eAnnotations>
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EReference" name="relationedEntities" upperBound="-1"
eType="#//AbstractEntity" changeable="false" volatile="true" transient="true"
derived="true" eOpposite="#//AbstractEntity/relatedEntities">
<eAnnotations source="http://www.eclipse.org/emf/2002/Ecore/OCL">
<details key="derivation" value="self.incommingRelations->collect(entity)"/>
</eAnnotations>
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EReference" name="relatedEntities" upperBound="-1"
eType="#//AbstractEntity" changeable="false" volatile="true" transient="true"
derived="true" eOpposite="#//AbstractEntity/relationedEntities">
<eAnnotations source="http://www.eclipse.org/emf/2002/Ecore/OCL">
<details key="derivation" value="self.outgoingRelations->collect(relatedEntity)"/>
</eAnnotations>
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="relations" upperBound="-1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EFeatureMapEntry">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="group"/>
</eAnnotations>
</eStructuralFeatures>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Building" eSuperTypes="#//AbstractEntity">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="street" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="zipCode" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="town" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Person" eSuperTypes="#//AbstractEntity">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="foreName" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="sureName" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="birthday" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EDate"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Car" eSuperTypes="#//AbstractEntity">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="type" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="seats" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="sign" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Relation">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="relationType" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="entity" eType="#//AbstractEntity"
eOpposite="#//AbstractEntity/outgoingRelations"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="relatedEntity" eType="#//AbstractEntity"
eOpposite="#//AbstractEntity/incommingRelations">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="href"/>
</eAnnotations>
</eStructuralFeatures>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="RootObject">
<eStructuralFeatures xsi:type="ecore:EReference" name="entitites" upperBound="-1"
eType="#//AbstractEntity" containment="true"/>
</eClassifiers>
</ecore:EPackage>

--------------040809020006030904060005--
Re: Complex Model Relationships [message #631454 is a reply to message #631403] Thu, 07 October 2010 14:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Keiko,

Comments below.

Heiko wrote:
> First: Sorry for cross - post, but maybe somebody of the EMF experts
> can help me at the abstract probem and for another point, I hope
> soneone of the OCL experts can help me.
>
>
>
> Outgoing from an old application and his datamodel , I want to rebuild
> it with EMF.
>
> Like the attached model, I have diffrent object types and all
> instances of it can have bidirectional releations to other instances.
> The problem here is that this relations not only simple but also I
> need to hold informations about every relation.
>
> For this problem I build an example based on:
> - the example from Ed Merks at:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=105920
>
> - FeatureMap Example from the EMF book 2nd Edt
>
> - my absolut minimal knowledge of OCL
>
>
> At the moment, my first problem are, that if I try to get the
> "related entities", I've got a NPE.
> Inside the OCLinEcoreEdito gets the following:
> (Here, I think my OCL code is wrong)
>
> class AbstractEntity { abstract }
> {
> attribute datetimeLastChg : ecore_0::EDate[?];
> attribute datetimeLastInfo : ecore_0::EDate[?];
> property incommingRelations#relatedEntity : Relation[*] {
> derived,transient,volatile,composes }
> {
> annotation
> 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name = 'entity',
> group = '#relations');
> }
> property outgoingRelations#entity : Relation[*] {
> derived,transient,volatile,composes }
> {
> annotation
> 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name =
> 'relatedEntity', group = '#relations');
> }
> property relationedEntities#relatedEntities :
> AbstractEntity[*] { readonly,derived,transient,volatile }
> {
> derivation: self.incommingRelations->collect(entity);
> }
> property relatedEntities#relationedEntities :
> AbstractEntity[*] { readonly,derived,transient,volatile }
> {
> derivation: self.outgoingRelations->collect(relatedEntity);
> }
> attribute relations : ecore_0::EFeatureMapEntry[*]
> {
> annotation
> 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(kind = 'group');
> }
> }
>
> How, I have to define, that I get all entities which are references
> inside the collection of relation objects inside the AbstractEntity
> object?
>
>
>
>
> The other question is more abstract:
> The attatched model is a simplified example of my first draft.
> But it shows my biggest problem what I have with, to define the
> relations between the objects.
Usually one would just define specific relationships. Ecore already
provides reflection that would allow you to determine all the
relationships that any object has EObject.eClass().getEAllReferences()
and then with reflection (eObject.eGet()) to fetch all the related objects.
>
> Had has somebody the same or similar problem to define such a complex
> releationship and can point me, how can I do is in a better way?
>
>
> Greetings
>
> Heiko


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Complex Model Relationships [message #631512 is a reply to message #631454] Thu, 07 October 2010 19:18 Go to previous messageGo to next message
Heiko Ahlig is currently offline Heiko AhligFriend
Messages: 62
Registered: July 2009
Member
Hi Ed,
thanks for your quick answer, but
your recommended solution dosen't help. :(

For a better understanding her some additional informations:
- the attached model shows only a very small excerpt:
+ the real model has over twenty "Main Object Types" for which I need
this complex relationships with additional informations
+ in the real model every "Main object Type" has normal "containment"
references and sub sub containments too, so that I have over
100 classes
+ the addtional relationship object type will have over 20 different
attributes


- Inside the old application:
+ the main objects have a special relationship object, but there are
only the information which type and ID has the related main object
but there a no direct access possible
+ at the persistence layer generates and/or updates the the relation
object and also does with his counter part

For the old web application it was ok, and every object could be loaded
with this informations, if you need it. For a modern RCP / RAP
application, maybe in addion with CDO the old relations system are not
realy usable (I think so).

An other idea, I have, are to define a "relation part" which will be
added as normal bidirectional containment reference and inside this I
have an 1<->1 non containment reference to his counter part.

I know that in all solutions the CRUD operations will need additional
code, but that will be ok.

Nice, in the end, should be an easy navigation over the relations to the
other entities (programaticly and with databinding) ;)

Greetings

Heiko

Am 07.10.2010 16:33, schrieb Ed Merks:
> Keiko,
>
> Comments below.
>
> Heiko wrote:
>> First: Sorry for cross - post, but maybe somebody of the EMF experts
>> can help me at the abstract probem and for another point, I hope
>> soneone of the OCL experts can help me.
>>
>>
>>
>> Outgoing from an old application and his datamodel , I want to rebuild
>> it with EMF.
>>
>> Like the attached model, I have diffrent object types and all
>> instances of it can have bidirectional releations to other instances.
>> The problem here is that this relations not only simple but also I
>> need to hold informations about every relation.
>>
>> For this problem I build an example based on:
>> - the example from Ed Merks at:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=105920
>>
>> - FeatureMap Example from the EMF book 2nd Edt
>>
>> - my absolut minimal knowledge of OCL
>>
>>
>> At the moment, my first problem are, that if I try to get the
>> "related entities", I've got a NPE.
>> Inside the OCLinEcoreEdito gets the following:
>> (Here, I think my OCL code is wrong)
>>
>> class AbstractEntity { abstract }
>> {
>> attribute datetimeLastChg : ecore_0::EDate[?];
>> attribute datetimeLastInfo : ecore_0::EDate[?];
>> property incommingRelations#relatedEntity : Relation[*] {
>> derived,transient,volatile,composes }
>> {
>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name
>> = 'entity', group = '#relations');
>> }
>> property outgoingRelations#entity : Relation[*] {
>> derived,transient,volatile,composes }
>> {
>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name
>> = 'relatedEntity', group = '#relations');
>> }
>> property relationedEntities#relatedEntities : AbstractEntity[*] {
>> readonly,derived,transient,volatile }
>> {
>> derivation: self.incommingRelations->collect(entity);
>> }
>> property relatedEntities#relationedEntities : AbstractEntity[*] {
>> readonly,derived,transient,volatile }
>> {
>> derivation: self.outgoingRelations->collect(relatedEntity);
>> }
>> attribute relations : ecore_0::EFeatureMapEntry[*]
>> {
>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(kind
>> = 'group');
>> }
>> }
>>
>> How, I have to define, that I get all entities which are references
>> inside the collection of relation objects inside the AbstractEntity
>> object?
>>
>>
>>
>>
>> The other question is more abstract:
>> The attatched model is a simplified example of my first draft.
>> But it shows my biggest problem what I have with, to define the
>> relations between the objects.
> Usually one would just define specific relationships. Ecore already
> provides reflection that would allow you to determine all the
> relationships that any object has EObject.eClass().getEAllReferences()
> and then with reflection (eObject.eGet()) to fetch all the related objects.
>>
>> Had has somebody the same or similar problem to define such a complex
>> releationship and can point me, how can I do is in a better way?
>>
>>
>> Greetings
>>
>> Heiko
Re: Complex Model Relationships [message #631514 is a reply to message #631512] Thu, 07 October 2010 19:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Heiko,

If the relationship really needs to carry additional attributes (which
isn't clear from the simple example) then you really will need to model
the relationships themselves as an object much like I showed in the blog
I wrote. Of course a variation of what I showed (which was focused on
keeping the storage of the relationships separate from the model
objects) would be to store the objects representing the relationship on
one of the sides (via a containment reference) and then have the
reference to the other side of the relation be a non-containment
reference in the relation object. I think that's what you're getting at
in your final comments.


Heiko Ahlig wrote:
> Hi Ed,
> thanks for your quick answer, but
> your recommended solution dosen't help. :(
>
> For a better understanding her some additional informations:
> - the attached model shows only a very small excerpt:
> + the real model has over twenty "Main Object Types" for which I need
> this complex relationships with additional informations
> + in the real model every "Main object Type" has normal "containment"
> references and sub sub containments too, so that I have over
> 100 classes
> + the addtional relationship object type will have over 20 different
> attributes
>
>
> - Inside the old application:
> + the main objects have a special relationship object, but there are
> only the information which type and ID has the related main object
> but there a no direct access possible
> + at the persistence layer generates and/or updates the the relation
> object and also does with his counter part
>
> For the old web application it was ok, and every object could be
> loaded with this informations, if you need it. For a modern RCP / RAP
> application, maybe in addion with CDO the old relations system are not
> realy usable (I think so).
>
> An other idea, I have, are to define a "relation part" which will be
> added as normal bidirectional containment reference and inside this I
> have an 1<->1 non containment reference to his counter part.
>
> I know that in all solutions the CRUD operations will need additional
> code, but that will be ok.
>
> Nice, in the end, should be an easy navigation over the relations to
> the other entities (programaticly and with databinding) ;)
>
> Greetings
>
> Heiko
>
> Am 07.10.2010 16:33, schrieb Ed Merks:
>> Keiko,
>>
>> Comments below.
>>
>> Heiko wrote:
>>> First: Sorry for cross - post, but maybe somebody of the EMF experts
>>> can help me at the abstract probem and for another point, I hope
>>> soneone of the OCL experts can help me.
>>>
>>>
>>>
>>> Outgoing from an old application and his datamodel , I want to rebuild
>>> it with EMF.
>>>
>>> Like the attached model, I have diffrent object types and all
>>> instances of it can have bidirectional releations to other instances.
>>> The problem here is that this relations not only simple but also I
>>> need to hold informations about every relation.
>>>
>>> For this problem I build an example based on:
>>> - the example from Ed Merks at:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=105920
>>>
>>> - FeatureMap Example from the EMF book 2nd Edt
>>>
>>> - my absolut minimal knowledge of OCL
>>>
>>>
>>> At the moment, my first problem are, that if I try to get the
>>> "related entities", I've got a NPE.
>>> Inside the OCLinEcoreEdito gets the following:
>>> (Here, I think my OCL code is wrong)
>>>
>>> class AbstractEntity { abstract }
>>> {
>>> attribute datetimeLastChg : ecore_0::EDate[?];
>>> attribute datetimeLastInfo : ecore_0::EDate[?];
>>> property incommingRelations#relatedEntity : Relation[*] {
>>> derived,transient,volatile,composes }
>>> {
>>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name
>>> = 'entity', group = '#relations');
>>> }
>>> property outgoingRelations#entity : Relation[*] {
>>> derived,transient,volatile,composes }
>>> {
>>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name
>>> = 'relatedEntity', group = '#relations');
>>> }
>>> property relationedEntities#relatedEntities : AbstractEntity[*] {
>>> readonly,derived,transient,volatile }
>>> {
>>> derivation: self.incommingRelations->collect(entity);
>>> }
>>> property relatedEntities#relationedEntities : AbstractEntity[*] {
>>> readonly,derived,transient,volatile }
>>> {
>>> derivation: self.outgoingRelations->collect(relatedEntity);
>>> }
>>> attribute relations : ecore_0::EFeatureMapEntry[*]
>>> {
>>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(kind
>>> = 'group');
>>> }
>>> }
>>>
>>> How, I have to define, that I get all entities which are references
>>> inside the collection of relation objects inside the AbstractEntity
>>> object?
>>>
>>>
>>>
>>>
>>> The other question is more abstract:
>>> The attatched model is a simplified example of my first draft.
>>> But it shows my biggest problem what I have with, to define the
>>> relations between the objects.
>> Usually one would just define specific relationships. Ecore already
>> provides reflection that would allow you to determine all the
>> relationships that any object has EObject.eClass().getEAllReferences()
>> and then with reflection (eObject.eGet()) to fetch all the related
>> objects.
>>>
>>> Had has somebody the same or similar problem to define such a complex
>>> releationship and can point me, how can I do is in a better way?
>>>
>>>
>>> Greetings
>>>
>>> Heiko


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Complex Model Relationships [message #631527 is a reply to message #631514] Thu, 07 October 2010 20:19 Go to previous message
Heiko Ahlig is currently offline Heiko AhligFriend
Messages: 62
Registered: July 2009
Member
This is a multi-part message in MIME format.
--------------080400000500030705060007
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Ed,
you are realy fast with your answers. :)

Yes we ned this addional informations. Some of the info are realy
important.
e.g. the association type, here some examples for the this (based on my
small model)
- car 1 can be "owned by" a organisation (Main Object Type) and is
"drived by" a person 1 at the time from day X till day Y

- car 2 is "owned by" a person 2 and this person 2 "lifes in" building 1

and so on ...

I have seen that some of your examples there keeping the relationships
outside the model objects.

A problem I've seen there are,
Our users looks with diffrent perspectives to the data and most time I
need only some of the related objects.
So I need to filter the objects and relations mot time based on the
information from the relationship object.

At the moment I hope, that I can use CDO and Databinding in the future,
but than I get the problem that the model will give me all relations
and at the databinding level I can't filter the data for the only
needed related objects.
If I hold the releation informations outside the models, I need to add
the "relationship holder" object to the JFace Viewers.
If I have the relation informations inside the model object I only have
to define the ViewerFilter without aksing the holder every time if an
object passes a filter or not.

I've seen I had not added the other draft for my relationship model at
the last post. :(

About this problem, I agonize since weeks and I jump from one part of
the problem to the other and in in the end I spin around. :(



Am 07.10.2010 21:33, schrieb Ed Merks:
> Heiko,
>
> If the relationship really needs to carry additional attributes (which
> isn't clear from the simple example) then you really will need to model
> the relationships themselves as an object much like I showed in the blog
> I wrote. Of course a variation of what I showed (which was focused on
> keeping the storage of the relationships separate from the model
> objects) would be to store the objects representing the relationship on
> one of the sides (via a containment reference) and then have the
> reference to the other side of the relation be a non-containment
> reference in the relation object. I think that's what you're getting at
> in your final comments.
>
>
> Heiko Ahlig wrote:
>> Hi Ed,
>> thanks for your quick answer, but
>> your recommended solution dosen't help. :(
>>
>> For a better understanding her some additional informations:
>> - the attached model shows only a very small excerpt:
>> + the real model has over twenty "Main Object Types" for which I need
>> this complex relationships with additional informations
>> + in the real model every "Main object Type" has normal "containment"
>> references and sub sub containments too, so that I have over
>> 100 classes
>> + the addtional relationship object type will have over 20 different
>> attributes
>>
>>
>> - Inside the old application:
>> + the main objects have a special relationship object, but there are
>> only the information which type and ID has the related main object
>> but there a no direct access possible
>> + at the persistence layer generates and/or updates the the relation
>> object and also does with his counter part
>>
>> For the old web application it was ok, and every object could be
>> loaded with this informations, if you need it. For a modern RCP / RAP
>> application, maybe in addion with CDO the old relations system are not
>> realy usable (I think so).
>>
>> An other idea, I have, are to define a "relation part" which will be
>> added as normal bidirectional containment reference and inside this I
>> have an 1<->1 non containment reference to his counter part.
>>
>> I know that in all solutions the CRUD operations will need additional
>> code, but that will be ok.
>>
>> Nice, in the end, should be an easy navigation over the relations to
>> the other entities (programaticly and with databinding) ;)
>>
>> Greetings
>>
>> Heiko
>>
>> Am 07.10.2010 16:33, schrieb Ed Merks:
>>> Keiko,
>>>
>>> Comments below.
>>>
>>> Heiko wrote:
>>>> First: Sorry for cross - post, but maybe somebody of the EMF experts
>>>> can help me at the abstract probem and for another point, I hope
>>>> soneone of the OCL experts can help me.
>>>>
>>>>
>>>>
>>>> Outgoing from an old application and his datamodel , I want to rebuild
>>>> it with EMF.
>>>>
>>>> Like the attached model, I have diffrent object types and all
>>>> instances of it can have bidirectional releations to other instances.
>>>> The problem here is that this relations not only simple but also I
>>>> need to hold informations about every relation.
>>>>
>>>> For this problem I build an example based on:
>>>> - the example from Ed Merks at:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=105920
>>>>
>>>> - FeatureMap Example from the EMF book 2nd Edt
>>>>
>>>> - my absolut minimal knowledge of OCL
>>>>
>>>>
>>>> At the moment, my first problem are, that if I try to get the
>>>> "related entities", I've got a NPE.
>>>> Inside the OCLinEcoreEdito gets the following:
>>>> (Here, I think my OCL code is wrong)
>>>>
>>>> class AbstractEntity { abstract }
>>>> {
>>>> attribute datetimeLastChg : ecore_0::EDate[?];
>>>> attribute datetimeLastInfo : ecore_0::EDate[?];
>>>> property incommingRelations#relatedEntity : Relation[*] {
>>>> derived,transient,volatile,composes }
>>>> {
>>>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name
>>>> = 'entity', group = '#relations');
>>>> }
>>>> property outgoingRelations#entity : Relation[*] {
>>>> derived,transient,volatile,composes }
>>>> {
>>>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(name
>>>> = 'relatedEntity', group = '#relations');
>>>> }
>>>> property relationedEntities#relatedEntities : AbstractEntity[*] {
>>>> readonly,derived,transient,volatile }
>>>> {
>>>> derivation: self.incommingRelations->collect(entity);
>>>> }
>>>> property relatedEntities#relationedEntities : AbstractEntity[*] {
>>>> readonly,derived,transient,volatile }
>>>> {
>>>> derivation: self.outgoingRelations->collect(relatedEntity);
>>>> }
>>>> attribute relations : ecore_0::EFeatureMapEntry[*]
>>>> {
>>>> annotation 'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'(kind
>>>> = 'group');
>>>> }
>>>> }
>>>>
>>>> How, I have to define, that I get all entities which are references
>>>> inside the collection of relation objects inside the AbstractEntity
>>>> object?
>>>>
>>>>
>>>>
>>>>
>>>> The other question is more abstract:
>>>> The attatched model is a simplified example of my first draft.
>>>> But it shows my biggest problem what I have with, to define the
>>>> relations between the objects.
>>> Usually one would just define specific relationships. Ecore already
>>> provides reflection that would allow you to determine all the
>>> relationships that any object has EObject.eClass().getEAllReferences()
>>> and then with reflection (eObject.eGet()) to fetch all the related
>>> objects.
>>>>
>>>> Had has somebody the same or similar problem to define such a complex
>>>> releationship and can point me, how can I do is in a better way?
>>>>
>>>>
>>>> Greetings
>>>>
>>>> Heiko

--------------080400000500030705060007
Content-Type: text/xml;
name="RelationshipExample_v2.ecore"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="RelationshipExample_v2.ecore"

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="relationship"
nsURI="http://techteam.de/2010/relationshipExample" nsPrefix="rs">
<eAnnotations source="http://www.eclipse.org/emf/2002/Ecore">
<details key="invocationDelegates" value="http://www.eclipse.org/emf/2002/Ecore/OCL"/>
<details key="settingDelegates" value="http://www.eclipse.org/emf/2002/Ecore/OCL"/>
<details key="validationDelegates" value="http://www.eclipse.org/emf/2002/Ecore/OCL"/>
</eAnnotations>
<eClassifiers xsi:type="ecore:EClass" name="AbstractEntity" abstract="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="datetimeLastChg" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EDate"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="datetimeLastInfo" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EDate"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="relatedEntities" upperBound="-1"
eType="#//AbstractEntity" changeable="false" volatile="true" transient="true"
derived="true">
<eAnnotations source="http://www.eclipse.org/emf/2002/Ecore/OCL">
<details key="derivation" value="self.outgoingRelations->collect(relatedEntity)"/>
</eAnnotations>
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EReference" name="relations" upperBound="-1"
eType="#//RelationPart" containment="true" eOpposite="#//RelationPart/entity"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Building" eSuperTypes="#//AbstractEntity">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="street" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="zipCode" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="town" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Person" eSuperTypes="#//AbstractEntity">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="foreName" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="sureName" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="birthday" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EDate"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Car" eSuperTypes="#//AbstractEntity">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="type" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="seats" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="sign" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="RelationPart">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="relationType" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="entity" eType="#//AbstractEntity"
eOpposite="#//AbstractEntity/relations"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="counterPart" lowerBound="1"
eType="#//RelationPart"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="RootObject">
<eStructuralFeatures xsi:type="ecore:EReference" name="entitites" upperBound="-1"
eType="#//AbstractEntity" containment="true"/>
</eClassifiers>
</ecore:EPackage>

--------------080400000500030705060007--
Previous Topic:[Announce] MDT/OCL 3.1.0 M2 is now available
Next Topic:Exceptions swallowed during evaluation
Goto Forum:
  


Current Time: Thu Mar 28 19:36:20 GMT 2024

Powered by FUDForum. Page generated in 0.07536 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top