Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc)

Help

Home

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Accessing a Container via OCL

Show: Today's Messages :: Show Polls :: Message Navigator

Accessing a Container via OCL [message #44216]

Thu, 10 August 2006 10:21

Alan Newton

Messages: 13
Registered: July 2009

Junior Member

I have the Model shown below:

Diagram
Nodes1 : references Nodes
Nodes2 : reference OtherNodes
:
:

Nodes
String Name
String Summary

etc.

and Nodes1 and Nodes2 are contained in the Diagram.

In the gmfgraph file, I can write OCL validation rules associated with
the Nodes object to ensure that the Name and Summary attributes are not
empty. Also within the GMF I can write an OCL validation rule associated
with the Digram that ensures that the Node Names are unique across the
diagram, e.g.:

self.Nodes1->forAll(n1,n2 |n1<>n2 implies n1.name<>n2.name)

However, when the error is reported this just identifies that there is a
duplicate within the DIAGRAM, not which nodes caused the error. Ideally
I would like to associated the error with the child node, the easiest
way to do this would be access the Container from the child node, is
there a way of accessing the container from a child node, e.g.:

self.CONTAINER.Nodes1 ->
forall( N | self<>N implies N.name=self.name))

If this was the case the error would then be correctly associated with
the child node.

I hope I am asking this question in the correct forum and any help would
be gratefully received.

Many thanks

Alan

Report message to a moderator

Re: Accessing a Container via OCL [message #44338 is a reply to message #44216]

Thu, 10 August 2006 13:09

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Hi, Alan,

Currently, OCL does not provide access to the reflective EObject API such as
eContainer(), eClass(), etc. unless your EClasses explicitly extend EObject
in your model. OCL only "sees" the types and features declared in your
ecore model. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=152003 for
details of an open enhancement request for this.

So, your two best possibilities at this point are:

a) add an explicit superclass reference to EObject in your Ecore model.
This is not so easy if you're dealing with the GMF Runtime's notation
model.
b) Provide a custom Environment implementation (extending
EcoreEnvironment) to provide eContainer() etc. as additional operations
and/or properties in your OCL environment. A corresponding custom
EvaluationEnvironment (extending EvalEnvironment) will then be
responsible for evaluating operation/property calls such as
eContainer() by invoking the corresponding EObject API.

HTH,

Christian

alan newton wrote:

> I have the Model shown below:
>
> Diagram
> Nodes1 : references Nodes
> Nodes2 : reference OtherNodes
> :
> :
>
> Nodes
> String Name
> String Summary
>
> etc.
>
>
> and Nodes1 and Nodes2 are contained in the Diagram.
>
>
> In the gmfgraph file, I can write OCL validation rules associated with
> the Nodes object to ensure that the Name and Summary attributes are not
> empty. Also within the GMF I can write an OCL validation rule associated
> with the Digram that ensures that the Node Names are unique across the
> diagram, e.g.:
>
> self.Nodes1->forAll(n1,n2 |n1<>n2 implies n1.name<>n2.name)
>
> However, when the error is reported this just identifies that there is a
> duplicate within the DIAGRAM, not which nodes caused the error. Ideally
> I would like to associated the error with the child node, the easiest
> way to do this would be access the Container from the child node, is
> there a way of accessing the container from a child node, e.g.:
>
> self.CONTAINER.Nodes1 ->
> forall( N | self<>N implies N.name=self.name))
>
> If this was the case the error would then be correctly associated with
> the child node.
>
> I hope I am asking this question in the correct forum and any help would
> be gratefully received.
>
> Many thanks
>
> Alan

Report message to a moderator

Re: Accessing a Container via OCL [message #44503 is a reply to message #44338]

Thu, 10 August 2006 14:33

Alan Newton

Messages: 13
Registered: July 2009

Junior Member

Hi Christian,

Thanks for your reply.

The Diagram objectcis the Top level object in me ECORE model, which
contains the set of reference to the Nodes. Is this still not accessable?

Alan

Christian W. Damus wrote:
> Hi, Alan,
>
> Currently, OCL does not provide access to the reflective EObject API such as
> eContainer(), eClass(), etc. unless your EClasses explicitly extend EObject
> in your model. OCL only "sees" the types and features declared in your
> ecore model. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=152003 for
> details of an open enhancement request for this.
>
> So, your two best possibilities at this point are:
>
> a) add an explicit superclass reference to EObject in your Ecore model.
> This is not so easy if you're dealing with the GMF Runtime's notation
> model.
> b) Provide a custom Environment implementation (extending
> EcoreEnvironment) to provide eContainer() etc. as additional operations
> and/or properties in your OCL environment. A corresponding custom
> EvaluationEnvironment (extending EvalEnvironment) will then be
> responsible for evaluating operation/property calls such as
> eContainer() by invoking the corresponding EObject API.
>
> HTH,
>
> Christian
>
>
> alan newton wrote:
>
>
>>I have the Model shown below:
>>
>>Diagram
>>Nodes1 : references Nodes
>>Nodes2 : reference OtherNodes
>>:
>>:
>>
>>Nodes
>>String Name
>>String Summary
>>
>>etc.
>>
>>
>>and Nodes1 and Nodes2 are contained in the Diagram.
>>
>>
>>In the gmfgraph file, I can write OCL validation rules associated with
>>the Nodes object to ensure that the Name and Summary attributes are not
>>empty. Also within the GMF I can write an OCL validation rule associated
>>with the Digram that ensures that the Node Names are unique across the
>>diagram, e.g.:
>>
>>self.Nodes1->forAll(n1,n2 |n1<>n2 implies n1.name<>n2.name)
>>
>>However, when the error is reported this just identifies that there is a
>>duplicate within the DIAGRAM, not which nodes caused the error. Ideally
>>I would like to associated the error with the child node, the easiest
>>way to do this would be access the Container from the child node, is
>>there a way of accessing the container from a child node, e.g.:
>>
>> self.CONTAINER.Nodes1 ->
>> forall( N | self<>N implies N.name=self.name))
>>
>>If this was the case the error would then be correctly associated with
>>the child node.
>>
>>I hope I am asking this question in the correct forum and any help would
>>be gratefully received.
>>
>>Many thanks
>>
>>Alan
>
>

Report message to a moderator

Re: Accessing a Container via OCL [message #44625 is a reply to message #44503]

Thu, 10 August 2006 14:58

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Hi, Alan,

I'm not sure what you mean by top level object in the ecore model. Do you
mean that in a diagram model instance, a Diagram instance will be the root
container (that contains everything else)?

OCL doesn't know anything about Resources, so you can't find an object by
its position in the Resource contents list. However, if you know that a
Resource will contain at most one Diagram instance, then you could use:

Diagram.allInstances()->asSequence()->first()

to get the one and only diagram, as allInstances() is scoped by default to
the Resource. Of course, this assumption may not be valid, in which case
your best bet still may be to add a Node::diagram reference to the diagram,
which might be transient and volatile, derived from eContainer().

Cheers,

Christian

alan newton wrote:

> Hi Christian,
>
> Thanks for your reply.
>
> The Diagram objectcis the Top level object in me ECORE model, which
> contains the set of reference to the Nodes. Is this still not accessable?
>
>
> Alan
>
> Christian W. Damus wrote:
>> Hi, Alan,
>>
>> Currently, OCL does not provide access to the reflective EObject API such
>> as eContainer(), eClass(), etc. unless your EClasses explicitly extend
>> EObject
>> in your model. OCL only "sees" the types and features declared in your
>> ecore model. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=152003
>> for details of an open enhancement request for this.
>>
>> So, your two best possibilities at this point are:
>>
>> a) add an explicit superclass reference to EObject in your Ecore model.
>> This is not so easy if you're dealing with the GMF Runtime's
>> notation model.
>> b) Provide a custom Environment implementation (extending
>> EcoreEnvironment) to provide eContainer() etc. as additional
>> operations
>> and/or properties in your OCL environment. A corresponding custom
>> EvaluationEnvironment (extending EvalEnvironment) will then be
>> responsible for evaluating operation/property calls such as
>> eContainer() by invoking the corresponding EObject API.
>>
>> HTH,
>>
>> Christian

<snip>

Report message to a moderator

Re: Accessing a Container via OCL [message #44689 is a reply to message #44625]

Thu, 10 August 2006 15:35

Alan Newton

Messages: 13
Registered: July 2009

Junior Member

Hi Christian,

Below is a pruned version of my Ecore model, the GSN Class is my top
level diagram which contains the collection of references to the Goal
Class. What I am trying to do is from a particular Goal is to go upto
the GSN Class and look in the collection of goals to make sure that only
one Goal with a particular name exists, and if a name exists elsewhere
in the set this particular node is marked as error.

I can write in OCL check at the GSN level to look for duplicate Goal
names, but this just identifies that an error exists not what the error is.

Hopes that clarifies what the model looks like and what I am attempting
to do.

thanks

Alan

<?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="eArgument"
nsURI="eArgument" nsPrefix="eArgument">
<eClassifiers xsi:type="ecore:EClass" name="Goal">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
:
:
</eClassifiers>

<eClassifiers xsi:type="ecore:EClass" name="GSN">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>

<eStructuralFeatures xsi:type="ecore:EReference" name="goals"
upperBound="-1"
eType="#//Goal" containment="true"/>
:
:
</eClassifiers>
:
:
</ecore:EPackage>

Christian W. Damus wrote:
> Hi, Alan,
>
> I'm not sure what you mean by top level object in the ecore model. Do you
> mean that in a diagram model instance, a Diagram instance will be the root
> container (that contains everything else)?
>
> OCL doesn't know anything about Resources, so you can't find an object by
> its position in the Resource contents list. However, if you know that a
> Resource will contain at most one Diagram instance, then you could use:
>
> Diagram.allInstances()->asSequence()->first()
>
> to get the one and only diagram, as allInstances() is scoped by default to
> the Resource. Of course, this assumption may not be valid, in which case
> your best bet still may be to add a Node::diagram reference to the diagram,
> which might be transient and volatile, derived from eContainer().
>
> Cheers,
>
> Christian
>
>
> alan newton wrote:
>
>
>>Hi Christian,
>>
>>Thanks for your reply.
>>
>>The Diagram objectcis the Top level object in me ECORE model, which
>>contains the set of reference to the Nodes. Is this still not accessable?
>>
>>
>>Alan
>>
>>Christian W. Damus wrote:
>>
>>>Hi, Alan,
>>>
>>>Currently, OCL does not provide access to the reflective EObject API such
>>>as eContainer(), eClass(), etc. unless your EClasses explicitly extend
>>>EObject
>>>in your model. OCL only "sees" the types and features declared in your
>>>ecore model. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=152003
>>>for details of an open enhancement request for this.
>>>
>>>So, your two best possibilities at this point are:
>>>
>>> a) add an explicit superclass reference to EObject in your Ecore model.
>>> This is not so easy if you're dealing with the GMF Runtime's
>>> notation model.
>>> b) Provide a custom Environment implementation (extending
>>> EcoreEnvironment) to provide eContainer() etc. as additional
>>> operations
>>> and/or properties in your OCL environment. A corresponding custom
>>> EvaluationEnvironment (extending EvalEnvironment) will then be
>>> responsible for evaluating operation/property calls such as
>>> eContainer() by invoking the corresponding EObject API.
>>>
>>>HTH,
>>>
>>>Christian
>>
>
> <snip>

Report message to a moderator

Re: Accessing a Container via OCL [message #44720 is a reply to message #44689]

Thu, 10 August 2006 17:45

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Hi, Alan,

If you make the changes that I indicated below in your ecore model (added a
Goal::gsn reference and updated the GSN::goals reference; see the text
between *...*), then you will be able to do:

self.gsn.goals->forAll(g | g <> self implies g.name <> self.name)

in the context of Goal. Otherwise, you can try:

self.eContainer().oclAsType(GSN).goals->forAll( ... )

if you take my original suggestion of implementing a custom Environment to
make the eContainer() operation available. For that matter, a "gns"
reference could be added by the Environment in the same way. I'm afraid
there isn't an example that demonstrates how to do this. It should be
quite straight-forward, though.

Cheers,

Christian

alan newton wrote:

> Hi Christian,
>
> Below is a pruned version of my Ecore model, the GSN Class is my top
> level diagram which contains the collection of references to the Goal
> Class. What I am trying to do is from a particular Goal is to go upto
> the GSN Class and look in the collection of goals to make sure that only
> one Goal with a particular name exists, and if a name exists elsewhere
> in the set this particular node is marked as error.
>
> I can write in OCL check at the GSN level to look for duplicate Goal
> names, but this just identifies that an error exists not what the error
> is.
>
> Hopes that clarifies what the model looks like and what I am attempting
> to do.
>
> thanks
>
> Alan
>
> <?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="eArgument"
> nsURI="eArgument" nsPrefix="eArgument">
> <eClassifiers xsi:type="ecore:EClass" name="Goal">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> *<eStructuralFeatures xsi:type="ecore:EReference" name="gsn"
> lowerBound="0"
> eType="#//GSN" eOpposite="#//GSN/goals"/>*
> :
> :
> </eClassifiers>
>
>
> <eClassifiers xsi:type="ecore:EClass" name="GSN">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="goals"
> upperBound="-1"
> eType="#//Goal" containment="true" *eOpposite="#//Goal/gsn"*/>
> :
> :
> </eClassifiers>
> :
> :
> </ecore:EPackage>
>
>
> Christian W. Damus wrote:
>> Hi, Alan,
>>
>> I'm not sure what you mean by top level object in the ecore model. Do
>> you mean that in a diagram model instance, a Diagram instance will be the
>> root container (that contains everything else)?
>>
>> OCL doesn't know anything about Resources, so you can't find an object by
>> its position in the Resource contents list. However, if you know that a
>> Resource will contain at most one Diagram instance, then you could use:
>>
>> Diagram.allInstances()->asSequence()->first()
>>
>> to get the one and only diagram, as allInstances() is scoped by default
>> to
>> the Resource. Of course, this assumption may not be valid, in which case
>> your best bet still may be to add a Node::diagram reference to the
>> diagram, which might be transient and volatile, derived from
>> eContainer().
>>
>> Cheers,
>>
>> Christian
>>
>>
>> alan newton wrote:
>>
>>

<snip>

Report message to a moderator

Re: Accessing a Container via OCL [message #44862 is a reply to message #44720]

Mon, 14 August 2006 13:28

Alan Newton

Messages: 13
Registered: July 2009

Junior Member

Hi Christian

Thanks for that, I took the first approach (i.e. a slight modification
to the model) and it works.

Alan

Christian W. Damus wrote:
> Hi, Alan,
>
> If you make the changes that I indicated below in your ecore model (added a
> Goal::gsn reference and updated the GSN::goals reference; see the text
> between *...*), then you will be able to do:
>
> self.gsn.goals->forAll(g | g <> self implies g.name <> self.name)
>
> in the context of Goal. Otherwise, you can try:
>
> self.eContainer().oclAsType(GSN).goals->forAll( ... )
>
> if you take my original suggestion of implementing a custom Environment to
> make the eContainer() operation available. For that matter, a "gns"
> reference could be added by the Environment in the same way. I'm afraid
> there isn't an example that demonstrates how to do this. It should be
> quite straight-forward, though.
>
> Cheers,
>
> Christian
>
>
> alan newton wrote:
>
>
>>Hi Christian,
>>
>>Below is a pruned version of my Ecore model, the GSN Class is my top
>>level diagram which contains the collection of references to the Goal
>>Class. What I am trying to do is from a particular Goal is to go upto
>>the GSN Class and look in the collection of goals to make sure that only
>> one Goal with a particular name exists, and if a name exists elsewhere
>>in the set this particular node is marked as error.
>>
>>I can write in OCL check at the GSN level to look for duplicate Goal
>>names, but this just identifies that an error exists not what the error
>>is.
>>
>>Hopes that clarifies what the model looks like and what I am attempting
>>to do.
>>
>>thanks
>>
>>Alan
>>
>><?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="eArgument"
>> nsURI="eArgument" nsPrefix="eArgument">
>> <eClassifiers xsi:type="ecore:EClass" name="Goal">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>lowerBound="1" eType="ecore:EDataType
>>http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> *<eStructuralFeatures xsi:type="ecore:EReference" name="gsn"
>>lowerBound="0"
>> eType="#//GSN" eOpposite="#//GSN/goals"/>*
>>:
>>:
>> </eClassifiers>
>>
>>
>> <eClassifiers xsi:type="ecore:EClass" name="GSN">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>>eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="goals"
>>upperBound="-1"
>> eType="#//Goal" containment="true" *eOpposite="#//Goal/gsn"*/>
>>:
>>:
>> </eClassifiers>
>>:
>>:
>></ecore:EPackage>
>>
>>
>>Christian W. Damus wrote:
>>
>>>Hi, Alan,
>>>
>>>I'm not sure what you mean by top level object in the ecore model. Do
>>>you mean that in a diagram model instance, a Diagram instance will be the
>>>root container (that contains everything else)?
>>>
>>>OCL doesn't know anything about Resources, so you can't find an object by
>>>its position in the Resource contents list. However, if you know that a
>>>Resource will contain at most one Diagram instance, then you could use:
>>>
>>> Diagram.allInstances()->asSequence()->first()
>>>
>>>to get the one and only diagram, as allInstances() is scoped by default
>>>to
>>>the Resource. Of course, this assumption may not be valid, in which case
>>>your best bet still may be to add a Node::diagram reference to the
>>>diagram, which might be transient and volatile, derived from
>>>eContainer().
>>>
>>>Cheers,
>>>
>>>Christian
>>>
>>>
>>>alan newton wrote:
>>>
>>>
>>
>
> <snip>

Report message to a moderator