Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » [OCLinEcore] eReference eKeys eOpposite
[OCLinEcore] eReference eKeys eOpposite [message #998772] Thu, 10 January 2013 17:13 Go to next message
Dan Simkins is currently offline Dan Simkins
Messages: 38
Registered: December 2012
Member
Hi,

I have constructed a simple ecore meta-model describing a root model element comprising one or more node and link elements. Each node and link has a uuid attribute which has the ID property set to true. Each node has an 'incoming' and 'outgoing' reference to a link, and similarly, each link has a 'from' and 'to' reference to a node. I use eReferences and the eOpposite feature, thus ensuring that on model construction, when setting a reference, the reverse reference is set automatically. Further, I am setting the eKeys property to the uuid of the referring element for the references to provide more robust serialisation.

Creating a model (see below) based on the given ecore meta-model (see below) works as expected.

The problem is that I now wish to add OCL constraints into the meta-model. I have seen a similar topic raised (message #558058) where issues where identified using eKeys in OCLinEcore. However, this is different in that the key is an attribute within a different class.

Any assistance would be great!

Dan

****************** META-MODEL ********************
<?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="test1" nsURI="http://test1/1.0" nsPrefix="test1">
<eClassifiers xsi:type="ecore:EClass" name="Model">
<eStructuralFeatures xsi:type="ecore:EReference" name="node" upperBound="-1" eType="#//Node"
containment="true"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="link" upperBound="-1" eType="#//Link"
containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Node">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="uuid" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="outgoing" eType="#//Link"
eOpposite="#//Link/from" eKeys="#//Link/uuid"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="incoming" eType="#//Link"
eOpposite="#//Link/to" eKeys="#//Link/uuid"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Link">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="uuid" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
defaultValueLiteral="" iD="true"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="from" lowerBound="1" eType="#//Node"
eOpposite="#//Node/outgoing" eKeys="#//Node/uuid"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="to" lowerBound="1" eType="#//Node"
eOpposite="#//Node/incoming" eKeys="#//Node/uuid"/>
</eClassifiers>
</ecore:EPackage>

****************** SAMPLE MODEL ********************
<?xml version="1.0" encoding="ASCII"?>
<test1:Model
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:test1="http://test1/1.0"
xsi:schemaLocation="http://test1/1.0 test1.ecore">
<node uuid="n1"
outgoing="l1"/>
<node uuid="n2"
incoming="l1"/>
<link uuid="l1"
from="n1"
to="n2"/>
</test1:Model>
Re: [OCLinEcore] eReference eKeys eOpposite [message #998862 is a reply to message #998772] Thu, 10 January 2013 21:01 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi

Your example demonstrates a new bug
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=397917) which can be
worked around by editing e.g.

property to#incoming : Node
{
key Node::uuid;
}

to remove the redundant qualification as

property to#incoming : Node
{
key uuid;
}

However, I think this is nothing to do with OCL. eKeys like xmi:id are
serialization detail not model content, so they are not naturally
accessible to OCL expressions.

You say you are doing this to "provide more robust serialisation".

Unless you are already an EMF expert, I would caution that you are
wasting your time by ignoring EMF's many built-in model-level
serialization capabilities such as UUIDs. If you want to improve
character-level integrity, add a checksum/error correcting
layer/encryption to your serialization. Using an unconventional approach
will make your serialization less robust as you uncover bugs in many of
the tools that you try to use.

Regards

Ed Willink

On 10/01/2013 17:13, Dan Simkins wrote:
> Hi,
>
> I have constructed a simple ecore meta-model describing a root model
> element comprising one or more node and link elements. Each node and
> link has a uuid attribute which has the ID property set to true. Each
> node has an 'incoming' and 'outgoing' reference to a link, and
> similarly, each link has a 'from' and 'to' reference to a node. I use
> eReferences and the eOpposite feature, thus ensuring that on model
> construction, when setting a reference, the reverse reference is set
> automatically. Further, I am setting the eKeys property to the uuid of
> the referring element for the references to provide more robust
> serialisation.
>
> Creating a model (see below) based on the given ecore meta-model (see
> below) works as expected.
>
> The problem is that I now wish to add OCL constraints into the
> meta-model. I have seen a similar topic raised (message #558058) where
> issues where identified using eKeys in OCLinEcore. However, this is
> different in that the key is an attribute within a different class.
>
> Any assistance would be great!
>
> Dan
>
> ****************** META-MODEL ********************
> <?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="test1"
> nsURI="http://test1/1.0" nsPrefix="test1">
> <eClassifiers xsi:type="ecore:EClass" name="Model">
> <eStructuralFeatures xsi:type="ecore:EReference" name="node"
> upperBound="-1" eType="#//Node"
> containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="link"
> upperBound="-1" eType="#//Link"
> containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Node">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="uuid"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="outgoing"
> eType="#//Link"
> eOpposite="#//Link/from" eKeys="#//Link/uuid"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="incoming"
> eType="#//Link"
> eOpposite="#//Link/to" eKeys="#//Link/uuid"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Link">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="uuid"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
> defaultValueLiteral="" iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="from"
> lowerBound="1" eType="#//Node"
> eOpposite="#//Node/outgoing" eKeys="#//Node/uuid"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="to"
> lowerBound="1" eType="#//Node"
> eOpposite="#//Node/incoming" eKeys="#//Node/uuid"/>
> </eClassifiers>
> </ecore:EPackage>
>
> ****************** SAMPLE MODEL ********************
> <?xml version="1.0" encoding="ASCII"?>
> <test1:Model
> xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:test1="http://test1/1.0"
> xsi:schemaLocation="http://test1/1.0 test1.ecore">
> <node uuid="n1"
> outgoing="l1"/>
> <node uuid="n2"
> incoming="l1"/>
> <link uuid="l1"
> from="n1"
> to="n2"/>
> </test1:Model>
Re: [OCLinEcore] eReference eKeys eOpposite [message #998880 is a reply to message #998862] Thu, 10 January 2013 22:10 Go to previous messageGo to next message
Dan Simkins is currently offline Dan Simkins
Messages: 38
Registered: December 2012
Member
Hi Ed,

Many thanks for taking the time to respond.

I am not trying to do anything clever with serialisation. What I have experienced (and found a number of references to - see http://www.eclipse.org/forums/index.php/mv/msg/133342/#msg_415779) is that serialisation of non-containment references uses a key based on the referenced elements position in the model file. It is this that I do not find particularly robust Smile

I have tried your work-around, however unfortunately when I save the file from the OCLinEcore editor and then re-validate the ecore meta-model, I get a validation error stating:"

"The key 'uuid : EString' must be feature of the reference's type test1.ecore /wfsTestModel/model Unknown EMF Problem"

Any further help or thoughts appreciated.

Kind regards

Dan
Re: [OCLinEcore] eReference eKeys eOpposite [message #999041 is a reply to message #998880] Fri, 11 January 2013 08:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi

If you want robustness against manual editing of XML files, then just
make sure that your Resource overrides XMLResourceIMpl.useIDs() or
XMLResourceIMpl.useUUIDs() to return true. As in
org.eclipse.ocl.examples.pivot.utilities.PivotResourceImpl.java.

Regards

Ed Willink

On 10/01/2013 22:10, Dan Simkins wrote:
> Hi Ed,
>
> Many thanks for taking the time to respond.
> I am not trying to do anything clever with serialisation. What I have
> experienced (and found a number of references to - see
> http://www.eclipse.org/forums/index.php/mv/msg/133342/#msg_415779) is
> that serialisation of non-containment references uses a key based on
> the referenced elements position in the model file. It is this that I
> do not find particularly robust :)
>
> I have tried your work-around, however unfortunately when I save the
> file from the OCLinEcore editor and then re-validate the ecore
> meta-model, I get a validation error stating:"
>
> "The key 'uuid : EString' must be feature of the reference's type
> test1.ecore /wfsTestModel/model Unknown EMF Problem"
>
> Any further help or thoughts appreciated.
>
> Kind regards
>
> Dan
Re: [OCLinEcore] eReference eKeys eOpposite [message #999234 is a reply to message #999041] Fri, 11 January 2013 15:57 Go to previous messageGo to next message
Dan Simkins is currently offline Dan Simkins
Messages: 38
Registered: December 2012
Member
Hi Ed,

Many thanks for your response. After a little more experimentation I have found that removal of the eKeys attribute from the eReferences using the ecore editor has no detrimental effect on serialisation - it is the setting of the ID attribute against the uuid that seems to force serialisation to use this uuid field. So, I am now happy as I can start to work in OCLinEcore!!

Thanks again for your assistance!

Dan
Re: [OCLinEcore] eReference eKeys eOpposite [message #999505 is a reply to message #999234] Sat, 12 January 2013 09:23 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
Dan,

Yes, IDs take precedence. If an object has an ID attribute, that will
be (by default) what a resource implementation uses (should use, if
possible) for locating that object within its containing resource
resource. Note also that eKeys induce a constraint that the combination
of the key attributes are unique in that reference, and they only affect
serialization (by default) when they are defined on containment
references, that's because it's the path from the root of the resource
via containment references to the referenced object that's used in the
fragment path, and it's those segments which use the key, rather than
the index, to navigate to the appropriate child. That's why the place
you defined the eKeys in your model had no visible effect, and could
even be deterimental because any links referring to nodes in other
resources would all expect those nodes to have unique uuid attributes
but there's no constraint that says nodes in different resources can't
have the same ID. You can consider defining the eKeys on your
Model.node reference (and should rename it to nodes to reflect its
multiplicity).


On 11/01/2013 4:57 PM, Dan Simkins wrote:
> Hi Ed,
>
> Many thanks for your response. After a little more experimentation I
> have found that removal of the eKeys attribute from the eReferences
> using the ecore editor has no detrimental effect on serialisation - it
> is the setting of the ID attribute against the uuid that seems to
> force serialisation to use this uuid field. So, I am now happy as I
> can start to work in OCLinEcore!!
>
> Thanks again for your assistance!
>
> Dan
Previous Topic:OCLinEcore - UI Dependency?
Next Topic:[OCL Console] Access Package of model
Goto Forum:
  


Current Time: Sun Sep 21 10:22:34 GMT 2014

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

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